@polymorphism-tech/morph-spec 3.1.0 → 3.2.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/CLAUDE.md +534 -0
- package/README.md +78 -4
- package/bin/morph-spec.js +50 -1
- package/bin/render-template.js +56 -10
- package/bin/task-manager.cjs +101 -7
- package/docs/cli-auto-detection.md +219 -0
- package/docs/llm-interaction-config.md +735 -0
- package/docs/troubleshooting.md +269 -0
- package/package.json +5 -1
- package/src/commands/advance-phase.js +93 -2
- package/src/commands/approve.js +221 -0
- package/src/commands/capture-pattern.js +121 -0
- package/src/commands/generate.js +128 -1
- package/src/commands/init.js +37 -0
- package/src/commands/migrate-state.js +158 -0
- package/src/commands/search-patterns.js +126 -0
- package/src/commands/spawn-team.js +172 -0
- package/src/commands/task.js +2 -2
- package/src/commands/update.js +36 -0
- package/src/commands/upgrade.js +346 -0
- package/src/generator/.gitkeep +0 -0
- package/src/generator/config-generator.js +206 -0
- package/src/generator/templates/config.json.template +40 -0
- package/src/generator/templates/project.md.template +67 -0
- package/src/lib/checkpoint-hooks.js +258 -0
- package/src/lib/metadata-extractor.js +380 -0
- package/src/lib/phase-state-machine.js +214 -0
- package/src/lib/state-manager.js +120 -0
- package/src/lib/template-data-sources.js +325 -0
- package/src/lib/validators/content-validator.js +351 -0
- package/src/llm/.gitkeep +0 -0
- package/src/llm/analyzer.js +215 -0
- package/src/llm/environment-detector.js +43 -0
- package/src/llm/few-shot-examples.js +216 -0
- package/src/llm/project-config-schema.json +188 -0
- package/src/llm/prompt-builder.js +96 -0
- package/src/llm/schema-validator.js +121 -0
- package/src/orchestrator.js +206 -0
- package/src/sanitizer/.gitkeep +0 -0
- package/src/sanitizer/context-sanitizer.js +221 -0
- package/src/sanitizer/patterns.js +163 -0
- package/src/scanner/.gitkeep +0 -0
- package/src/scanner/project-scanner.js +242 -0
- package/src/types/index.js +477 -0
- package/src/ui/.gitkeep +0 -0
- package/src/ui/diff-display.js +91 -0
- package/src/ui/interactive-wizard.js +96 -0
- package/src/ui/user-review.js +211 -0
- package/src/ui/wizard-questions.js +190 -0
- package/src/writer/.gitkeep +0 -0
- package/src/writer/file-writer.js +86 -0
package/CLAUDE.md
CHANGED
|
@@ -52,6 +52,540 @@ cp stacks/{stack}/CLAUDE.md seu-projeto/CLAUDE.md
|
|
|
52
52
|
|
|
53
53
|
---
|
|
54
54
|
|
|
55
|
+
## APPROVAL GATES (Portões de Aprovação)
|
|
56
|
+
|
|
57
|
+
O sistema agora rastreia aprovações explícitas para cada fase crítica em `state.json`.
|
|
58
|
+
|
|
59
|
+
### Gates Obrigatórios
|
|
60
|
+
|
|
61
|
+
| Gate | Quando | Bloqueio | Comando |
|
|
62
|
+
|------|--------|----------|---------|
|
|
63
|
+
| **design** | Após DESIGN concluído | Impede `design → clarify` | `npx morph-spec approve {feature} design` |
|
|
64
|
+
| **tasks** | Após TASKS concluído | Impede `tasks → implement` | `npx morph-spec approve {feature} tasks` |
|
|
65
|
+
|
|
66
|
+
### Workflow com Approval Gates
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
# 1. Completar fase DESIGN
|
|
70
|
+
# Sistema gera: spec.md, contracts, decisions.md
|
|
71
|
+
|
|
72
|
+
# 2. PAUSAR e apresentar ao usuário
|
|
73
|
+
# Use AskUserQuestion: "Approve design to proceed to clarify phase?"
|
|
74
|
+
|
|
75
|
+
# 3. Se aprovado pelo usuário:
|
|
76
|
+
npx morph-spec approve {feature} design
|
|
77
|
+
|
|
78
|
+
# 4. Avançar fase (agora permitido)
|
|
79
|
+
npx morph-spec advance-phase {feature} clarify
|
|
80
|
+
|
|
81
|
+
# 5. Mesmo processo para TASKS → IMPLEMENT
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### Comandos de Approval
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
# Aprovar gate
|
|
88
|
+
npx morph-spec approve {feature} {gate}
|
|
89
|
+
|
|
90
|
+
# Rejeitar com motivo
|
|
91
|
+
npx morph-spec reject {feature} {gate} "Reason here"
|
|
92
|
+
|
|
93
|
+
# Ver status de todas as aprovações
|
|
94
|
+
npx morph-spec approval-status {feature}
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### Overrides (Usar com Cuidado)
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
# Pular verificação de aprovação (não recomendado)
|
|
101
|
+
npx morph-spec advance-phase {feature} {next-phase} --skip-approval
|
|
102
|
+
|
|
103
|
+
# Forçar transição inválida (emergências apenas)
|
|
104
|
+
npx morph-spec advance-phase {feature} {next-phase} --force
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
**REGRA CRÍTICA:** SEMPRE apresente outputs ao usuário e obtenha aprovação explícita antes de avançar de DESIGN ou TASKS.
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## AUTOMATIC CHECKPOINTS (Validação Automática)
|
|
112
|
+
|
|
113
|
+
A cada 3 tasks completadas, o sistema executa validação automática.
|
|
114
|
+
|
|
115
|
+
### O Que é Validado
|
|
116
|
+
|
|
117
|
+
| Validator | O Que Verifica | Falha Bloqueia? |
|
|
118
|
+
|-----------|----------------|-----------------|
|
|
119
|
+
| **architecture** | DI patterns, Blazor lifecycle, async/await | ✅ Sim |
|
|
120
|
+
| **packages** | Conflitos NuGet, versões incompatíveis | ✅ Sim |
|
|
121
|
+
| **design-system** | CSS compliance, color palette, spacing | ⚠️ Warning |
|
|
122
|
+
| **security** | Secrets expostos, SQL injection, XSS | ✅ Sim |
|
|
123
|
+
|
|
124
|
+
### Comportamento no Checkpoint
|
|
125
|
+
|
|
126
|
+
```bash
|
|
127
|
+
# Task 3, 6, 9, 12... completadas
|
|
128
|
+
🔍 Running CHECKPOINT 1...
|
|
129
|
+
✅ Architecture: 0 violations
|
|
130
|
+
✅ Packages: 0 conflicts
|
|
131
|
+
⚠️ Design System: 2 warnings (non-blocking)
|
|
132
|
+
✅ Security: 0 issues
|
|
133
|
+
|
|
134
|
+
✅ Checkpoint 1 passed
|
|
135
|
+
|
|
136
|
+
# Se checkpoint FALHAR:
|
|
137
|
+
❌ Checkpoint 2 failed!
|
|
138
|
+
- Architecture: DbContext injected directly in component
|
|
139
|
+
- Security: API key hardcoded in appsettings.json
|
|
140
|
+
|
|
141
|
+
❌ Task NOT marked done. Fix violations before proceeding.
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
### Configuração
|
|
145
|
+
|
|
146
|
+
Edite `.morph/config/llm-interaction.json`:
|
|
147
|
+
|
|
148
|
+
```json
|
|
149
|
+
{
|
|
150
|
+
"checkpoints": {
|
|
151
|
+
"frequency": 3,
|
|
152
|
+
"autoValidate": true,
|
|
153
|
+
"validators": {
|
|
154
|
+
"enabled": ["architecture", "packages", "security"]
|
|
155
|
+
},
|
|
156
|
+
"onFailure": {
|
|
157
|
+
"blockProgress": true,
|
|
158
|
+
"maxRetries": 3
|
|
159
|
+
}
|
|
160
|
+
}
|
|
161
|
+
}
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
**IMPORTANTE:** Se checkpoint falha 3 vezes, use `AskUserQuestion` para decidir: simplificar implementação, pular validador (arriscado), ou escalar para troubleshooting-expert.
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
## PHASE VALIDATION RULES (Validação Estrita)
|
|
169
|
+
|
|
170
|
+
O sistema agora impede transições de fase inválidas com **state machine**.
|
|
171
|
+
|
|
172
|
+
### Transições Válidas
|
|
173
|
+
|
|
174
|
+
```
|
|
175
|
+
proposal → setup
|
|
176
|
+
setup → uiux | design
|
|
177
|
+
uiux → design
|
|
178
|
+
design → clarify
|
|
179
|
+
clarify → tasks
|
|
180
|
+
tasks → implement
|
|
181
|
+
implement → sync | archived
|
|
182
|
+
sync → archived
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
### 5 Gates de Validação
|
|
186
|
+
|
|
187
|
+
Ao avançar fase, o sistema verifica (em ordem):
|
|
188
|
+
|
|
189
|
+
1. **State Machine:** Transição é válida? (`proposal → implement` ❌)
|
|
190
|
+
2. **Approval Gates:** Gate foi aprovado? (`design` ou `tasks` gates)
|
|
191
|
+
3. **Output Requirements:** Arquivos obrigatórios existem? (spec.md, tasks.json)
|
|
192
|
+
4. **Spec Content:** `spec.md` tem todas as seções? (Overview, Requirements, Technical Design, Data Model, API Contracts)
|
|
193
|
+
5. **Tasks Content:** `tasks.json` tem estrutura válida? (IDs, descriptions, dependencies válidas, sem ciclos)
|
|
194
|
+
|
|
195
|
+
### Exemplo de Bloqueio
|
|
196
|
+
|
|
197
|
+
```bash
|
|
198
|
+
npx morph-spec advance-phase user-auth implement
|
|
199
|
+
|
|
200
|
+
❌ Invalid phase transition: design → implement
|
|
201
|
+
Valid next phases: clarify
|
|
202
|
+
|
|
203
|
+
❌ Approval gate 'design' not approved
|
|
204
|
+
Run: npx morph-spec approve user-auth design
|
|
205
|
+
|
|
206
|
+
❌ Spec validation failed:
|
|
207
|
+
- Missing section: ## Data Model
|
|
208
|
+
- Missing section: ## API Contracts
|
|
209
|
+
|
|
210
|
+
Fix these issues before proceeding.
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
**REGRA:** Nunca pule fases. Se precisa pular (ex: feature simples sem UIUX), documente em `decisions.md` ADR e use `--force`.
|
|
214
|
+
|
|
215
|
+
---
|
|
216
|
+
|
|
217
|
+
## AGENT INVOCATION PATTERNS (Spawning de Agentes)
|
|
218
|
+
|
|
219
|
+
Use **Task tool** para spawnar subagentes quando apropriado.
|
|
220
|
+
|
|
221
|
+
### Quando Spawnar Agentes
|
|
222
|
+
|
|
223
|
+
Spawnar subagentes quando:
|
|
224
|
+
|
|
225
|
+
- **5+ agentes ativos** (conforme state.activeAgents)
|
|
226
|
+
- **Multi-domínio** (backend + frontend + infra)
|
|
227
|
+
- **15+ arquivos** a modificar
|
|
228
|
+
- **Complexidade: high ou critical**
|
|
229
|
+
|
|
230
|
+
### Pattern 1: Squad Leader Spawning
|
|
231
|
+
|
|
232
|
+
```typescript
|
|
233
|
+
// Use Task tool
|
|
234
|
+
{
|
|
235
|
+
subagent_type: "general-purpose",
|
|
236
|
+
description: "Implement backend API layer",
|
|
237
|
+
prompt: `You are the Backend Squad Leader (dotnet-senior)...
|
|
238
|
+
|
|
239
|
+
Your Domain Leaders:
|
|
240
|
+
- ef-modeler: Database/EF Core layer
|
|
241
|
+
- api-designer: REST endpoints + DTOs
|
|
242
|
+
- event-architect: Domain events + Hangfire jobs
|
|
243
|
+
|
|
244
|
+
Your Mission: Implement user authentication API
|
|
245
|
+
|
|
246
|
+
Feature Spec: [Include spec.md summary]
|
|
247
|
+
|
|
248
|
+
Standards:
|
|
249
|
+
- .morph/standards/coding.md
|
|
250
|
+
- .morph/standards/architecture.md
|
|
251
|
+
- .morph/standards/dotnet10-compatibility.md
|
|
252
|
+
|
|
253
|
+
Your Tasks (from tasks.json):
|
|
254
|
+
- T001: Create User entity + DbContext
|
|
255
|
+
- T002: Implement UserService with password hashing
|
|
256
|
+
- T003: Create AuthController with login/register endpoints
|
|
257
|
+
|
|
258
|
+
Deliverables:
|
|
259
|
+
- Entities/User.cs
|
|
260
|
+
- Data/AppDbContext.cs
|
|
261
|
+
- Services/UserService.cs
|
|
262
|
+
- Controllers/AuthController.cs
|
|
263
|
+
- DTOs (LoginRequest, RegisterRequest, AuthResponse)
|
|
264
|
+
- Migrations
|
|
265
|
+
|
|
266
|
+
Constraints:
|
|
267
|
+
- Use IDbContextFactory (not direct DbContext injection)
|
|
268
|
+
- BCrypt for password hashing
|
|
269
|
+
- JWT tokens (not sessions)
|
|
270
|
+
|
|
271
|
+
Report back when complete with file list + any blockers.`
|
|
272
|
+
}
|
|
273
|
+
```
|
|
274
|
+
|
|
275
|
+
### Pattern 2: Get Team Hierarchy Helper
|
|
276
|
+
|
|
277
|
+
```bash
|
|
278
|
+
# Gera configurações prontas para Task tool
|
|
279
|
+
npx morph-spec spawn-team {feature}
|
|
280
|
+
|
|
281
|
+
# Output: JSON configs para cada squadmate
|
|
282
|
+
{
|
|
283
|
+
"teammates": [
|
|
284
|
+
{
|
|
285
|
+
"agent": "dotnet-senior",
|
|
286
|
+
"role": "Backend Squad Leader",
|
|
287
|
+
"taskConfig": { ... }
|
|
288
|
+
},
|
|
289
|
+
{
|
|
290
|
+
"agent": "ef-modeler",
|
|
291
|
+
"role": "Database Layer",
|
|
292
|
+
"taskConfig": { ... }
|
|
293
|
+
}
|
|
294
|
+
]
|
|
295
|
+
}
|
|
296
|
+
```
|
|
297
|
+
|
|
298
|
+
### Pattern 3: Sequential Handoff
|
|
299
|
+
|
|
300
|
+
```typescript
|
|
301
|
+
// 1. Backend squad gera API contracts
|
|
302
|
+
Task tool → dotnet-senior → generates contracts.cs
|
|
303
|
+
|
|
304
|
+
// 2. AGUARDAR conclusão (não spawnar frontend ainda)
|
|
305
|
+
|
|
306
|
+
// 3. Frontend squad usa contracts no contexto
|
|
307
|
+
Task tool → nextjs-senior → uses contracts.cs for type generation
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
### Agent Context Template
|
|
311
|
+
|
|
312
|
+
Use `.morph/templates/agent-context.md` para gerar contexto consistente:
|
|
313
|
+
|
|
314
|
+
```bash
|
|
315
|
+
node bin/render-template.js agent-context \
|
|
316
|
+
--feature=user-auth \
|
|
317
|
+
--agent=dotnet-senior \
|
|
318
|
+
--output=.morph/temp/agent-context.txt
|
|
319
|
+
```
|
|
320
|
+
|
|
321
|
+
**REGRA:** Sempre inclua spec.md summary, standards relevantes, e tasks específicas no prompt do agente.
|
|
322
|
+
|
|
323
|
+
---
|
|
324
|
+
|
|
325
|
+
## METADATA & QUICK ACCESS (Acesso Rápido)
|
|
326
|
+
|
|
327
|
+
Para features grandes, use `metadata.json` para acesso rápido (reduz uso de tokens em 60-80%).
|
|
328
|
+
|
|
329
|
+
### Quando Usar metadata.json
|
|
330
|
+
|
|
331
|
+
**USE metadata.json para:**
|
|
332
|
+
- Quick status (fase atual, progresso %)
|
|
333
|
+
- Lista de agentes ativos
|
|
334
|
+
- Resumo de decisões (ADRs com links)
|
|
335
|
+
- Histórico de checkpoints
|
|
336
|
+
|
|
337
|
+
**USE arquivos .md completos para:**
|
|
338
|
+
- Spec técnico detalhado
|
|
339
|
+
- User stories completas
|
|
340
|
+
- Diagramas e arquitetura
|
|
341
|
+
|
|
342
|
+
### Estrutura do metadata.json
|
|
343
|
+
|
|
344
|
+
```json
|
|
345
|
+
{
|
|
346
|
+
"version": "1.0.0",
|
|
347
|
+
"feature": "user-authentication",
|
|
348
|
+
"status": "active",
|
|
349
|
+
"phase": "implement",
|
|
350
|
+
|
|
351
|
+
"spec": {
|
|
352
|
+
"id": "user-auth",
|
|
353
|
+
"status": "Approved",
|
|
354
|
+
"complexity": "Medium",
|
|
355
|
+
"summary": {
|
|
356
|
+
"problem": "Users need secure login/register...",
|
|
357
|
+
"solution": "JWT-based auth with BCrypt...",
|
|
358
|
+
"tags": ["security", "authentication", "jwt"]
|
|
359
|
+
},
|
|
360
|
+
"requirements": ["REQ1: JWT tokens", "REQ2: BCrypt hashing"],
|
|
361
|
+
"dataModel": ["User entity", "RefreshToken entity"]
|
|
362
|
+
},
|
|
363
|
+
|
|
364
|
+
"decisions": {
|
|
365
|
+
"decisions": [
|
|
366
|
+
{
|
|
367
|
+
"id": "ADR-001",
|
|
368
|
+
"title": "JWT vs Sessions",
|
|
369
|
+
"summary": "Chose JWT for stateless auth...",
|
|
370
|
+
"fullPath": ".morph/features/user-auth/decisions.md#adr-001"
|
|
371
|
+
}
|
|
372
|
+
]
|
|
373
|
+
},
|
|
374
|
+
|
|
375
|
+
"tasks": {
|
|
376
|
+
"total": 12,
|
|
377
|
+
"completed": 8,
|
|
378
|
+
"progress": "67%"
|
|
379
|
+
},
|
|
380
|
+
|
|
381
|
+
"agents": ["dotnet-senior", "ef-modeler", "api-designer"],
|
|
382
|
+
|
|
383
|
+
"checkpoints": [
|
|
384
|
+
{ "num": 1, "passed": true, "timestamp": "2026-02-14T10:30:00Z" },
|
|
385
|
+
{ "num": 2, "passed": true, "timestamp": "2026-02-14T11:45:00Z" }
|
|
386
|
+
],
|
|
387
|
+
|
|
388
|
+
"quickLinks": {
|
|
389
|
+
"spec": ".morph/features/user-auth/spec.md",
|
|
390
|
+
"tasks": ".morph/features/user-auth/tasks.json",
|
|
391
|
+
"decisions": ".morph/features/user-auth/decisions.md"
|
|
392
|
+
}
|
|
393
|
+
}
|
|
394
|
+
```
|
|
395
|
+
|
|
396
|
+
### Workflow
|
|
397
|
+
|
|
398
|
+
```bash
|
|
399
|
+
# 1. Antes de trabalhar na feature, leia metadata.json
|
|
400
|
+
cat .morph/project/outputs/user-auth/metadata.json
|
|
401
|
+
|
|
402
|
+
# 2. Metadata auto-atualizado após cada task
|
|
403
|
+
# (Configurado em llm-interaction.json: "updateFrequency": "on_task_done")
|
|
404
|
+
|
|
405
|
+
# 3. Ou gere manualmente
|
|
406
|
+
npx morph-spec generate metadata user-auth
|
|
407
|
+
```
|
|
408
|
+
|
|
409
|
+
### Configuração
|
|
410
|
+
|
|
411
|
+
```json
|
|
412
|
+
{
|
|
413
|
+
"metadata": {
|
|
414
|
+
"autoGenerate": true,
|
|
415
|
+
"updateFrequency": "on_task_done"
|
|
416
|
+
}
|
|
417
|
+
}
|
|
418
|
+
```
|
|
419
|
+
|
|
420
|
+
---
|
|
421
|
+
|
|
422
|
+
## LEARNING SYSTEM (Biblioteca de Patterns)
|
|
423
|
+
|
|
424
|
+
Capture e reutilize patterns bem-sucedidos em `.morph/memory/patterns-learned.md`.
|
|
425
|
+
|
|
426
|
+
### Antes de Começar Nova Feature
|
|
427
|
+
|
|
428
|
+
```bash
|
|
429
|
+
# Buscar patterns relevantes
|
|
430
|
+
npx morph-spec search-patterns "blazor state"
|
|
431
|
+
npx morph-spec search-patterns "background job"
|
|
432
|
+
npx morph-spec search-patterns "bicep naming"
|
|
433
|
+
|
|
434
|
+
# Output:
|
|
435
|
+
🔍 Found 3 pattern(s) for: "blazor state"
|
|
436
|
+
|
|
437
|
+
1. Blazor DbContext Lifecycle
|
|
438
|
+
Category: Anti-Pattern to Avoid
|
|
439
|
+
Source: Framework standard
|
|
440
|
+
|
|
441
|
+
Problem: Directly injecting DbContext in Blazor components...
|
|
442
|
+
|
|
443
|
+
Correct Approach:
|
|
444
|
+
[Inject] IDbContextFactory<AppDbContext> DbFactory { get; set; }
|
|
445
|
+
...
|
|
446
|
+
```
|
|
447
|
+
|
|
448
|
+
### Após Completar Feature
|
|
449
|
+
|
|
450
|
+
```bash
|
|
451
|
+
# Capturar pattern bem-sucedido
|
|
452
|
+
npx morph-spec capture-pattern user-auth success "JWT refresh token rotation"
|
|
453
|
+
|
|
454
|
+
# Capturar anti-pattern (o que evitar)
|
|
455
|
+
npx morph-spec capture-pattern user-auth avoid "Storing tokens in localStorage"
|
|
456
|
+
|
|
457
|
+
# Capturar otimização
|
|
458
|
+
npx morph-spec capture-pattern user-auth optimization "EF Core query splitting for N+1"
|
|
459
|
+
```
|
|
460
|
+
|
|
461
|
+
### Categorias de Patterns
|
|
462
|
+
|
|
463
|
+
| Categoria | Quando Usar |
|
|
464
|
+
|-----------|-------------|
|
|
465
|
+
| `success` | Abordagens comprovadas para replicar |
|
|
466
|
+
| `avoid` | Anti-patterns e erros cometidos |
|
|
467
|
+
| `optimization` | Melhorias de performance |
|
|
468
|
+
| `security` | Best practices de segurança |
|
|
469
|
+
| `convention` | Convenções do projeto (naming, estrutura) |
|
|
470
|
+
| `best-practice` | Práticas gerais recomendadas |
|
|
471
|
+
|
|
472
|
+
### Pattern Library Pré-Seeded
|
|
473
|
+
|
|
474
|
+
O framework já vem com 11 patterns em `.morph/memory/patterns-learned.md`:
|
|
475
|
+
|
|
476
|
+
- Blazor DbContext Lifecycle (anti-pattern)
|
|
477
|
+
- Background Job Retry Strategy (best practice)
|
|
478
|
+
- Azure Bicep Resource Naming (convention)
|
|
479
|
+
- API Versioning Strategy (architecture)
|
|
480
|
+
- EF Core Migration Naming (convention)
|
|
481
|
+
- Blazor DI Registration Order (best practice)
|
|
482
|
+
- Component Parameter Validation (best practice)
|
|
483
|
+
- Async Method Naming (convention)
|
|
484
|
+
- Error Handling Strategy (best practice)
|
|
485
|
+
- Bicep Output Exports (convention)
|
|
486
|
+
- Azure Key Vault Secrets (security)
|
|
487
|
+
|
|
488
|
+
**REGRA:** Sempre busque patterns antes de começar. Capture patterns após completar. Biblioteca cresce com o tempo.
|
|
489
|
+
|
|
490
|
+
---
|
|
491
|
+
|
|
492
|
+
## INTERACTIVE DECISIONS (Decisões Estruturadas)
|
|
493
|
+
|
|
494
|
+
Use **AskUserQuestion** com templates estruturados em `.morph/templates/decision-prompts.md`.
|
|
495
|
+
|
|
496
|
+
### Quando Usar AskUserQuestion
|
|
497
|
+
|
|
498
|
+
**SEMPRE use para:**
|
|
499
|
+
- Escolhas arquiteturais (múltiplas abordagens válidas)
|
|
500
|
+
- Clarificação de escopo (requisitos ambíguos)
|
|
501
|
+
- Override de validators (checkpoint failures)
|
|
502
|
+
- Pular fases (features simples sem UIUX)
|
|
503
|
+
- Breaking changes (API versioning, migrations)
|
|
504
|
+
|
|
505
|
+
### Pattern 1: Arquitetura Choice
|
|
506
|
+
|
|
507
|
+
```markdown
|
|
508
|
+
I've designed two approaches for "user-authentication":
|
|
509
|
+
|
|
510
|
+
**Option A: JWT with HttpOnly Cookies**
|
|
511
|
+
- Pros: XSS protection, automatic CSRF with SameSite
|
|
512
|
+
- Cons: Harder CORS, mobile app compatibility
|
|
513
|
+
- Cost: +2 tasks (CSRF middleware)
|
|
514
|
+
|
|
515
|
+
**Option B: JWT in Authorization Header**
|
|
516
|
+
- Pros: Simpler CORS, better mobile support
|
|
517
|
+
- Cons: Requires manual XSS protection
|
|
518
|
+
- Cost: +1 task (XSS sanitization)
|
|
519
|
+
|
|
520
|
+
Recommendation: Option A (more secure for web apps)
|
|
521
|
+
|
|
522
|
+
Which approach do you prefer?
|
|
523
|
+
```
|
|
524
|
+
|
|
525
|
+
### Pattern 2: Scope Clarification
|
|
526
|
+
|
|
527
|
+
```markdown
|
|
528
|
+
Analyzing "scheduled-reports" feature. Need clarification:
|
|
529
|
+
|
|
530
|
+
1. **Scope:** Include email delivery or just generation?
|
|
531
|
+
2. **Users:** For admins only or all authenticated users?
|
|
532
|
+
3. **Priority:** Critical (deploy this week) or enhancement (iterate)?
|
|
533
|
+
4. **Format:** PDF only or PDF + Excel + CSV?
|
|
534
|
+
|
|
535
|
+
Please clarify so I can generate accurate spec.
|
|
536
|
+
```
|
|
537
|
+
|
|
538
|
+
### Pattern 3: Validator Override
|
|
539
|
+
|
|
540
|
+
```markdown
|
|
541
|
+
Checkpoint failed 3 times:
|
|
542
|
+
|
|
543
|
+
**Error:** Architecture validator - "DbContext injected directly in ReportsPage.razor"
|
|
544
|
+
|
|
545
|
+
**Attempts:**
|
|
546
|
+
1. Tried refactoring to service layer - still triggered (service was scoped)
|
|
547
|
+
2. Tried IDbContextFactory - validator didn't detect pattern
|
|
548
|
+
3. Re-read architecture.md - our implementation is correct per standard
|
|
549
|
+
|
|
550
|
+
**Options:**
|
|
551
|
+
1. Skip architecture validator for this checkpoint (risky)
|
|
552
|
+
2. Simplify implementation (use in-memory data, no DB)
|
|
553
|
+
3. Escalate to troubleshooting-expert agent
|
|
554
|
+
4. Pause for your guidance
|
|
555
|
+
|
|
556
|
+
What should I do?
|
|
557
|
+
```
|
|
558
|
+
|
|
559
|
+
### Pattern 4: Task Ordering
|
|
560
|
+
|
|
561
|
+
```markdown
|
|
562
|
+
Task dependency conflict detected in "user-auth":
|
|
563
|
+
|
|
564
|
+
**Circular dependency:**
|
|
565
|
+
- T003 (AuthController) depends on T005 (JWT service)
|
|
566
|
+
- T005 (JWT service) depends on T003 (AuthController contracts)
|
|
567
|
+
|
|
568
|
+
**Proposed resolution:**
|
|
569
|
+
1. Split T003 into T003a (contracts/DTOs) and T003b (controller implementation)
|
|
570
|
+
2. Order: T003a → T005 → T003b
|
|
571
|
+
|
|
572
|
+
Approve this task breakdown?
|
|
573
|
+
```
|
|
574
|
+
|
|
575
|
+
### Templates Disponíveis
|
|
576
|
+
|
|
577
|
+
Veja `.morph/templates/decision-prompts.md` para templates completos:
|
|
578
|
+
- Scope Clarification
|
|
579
|
+
- Architecture Choice
|
|
580
|
+
- Task Ordering Conflict
|
|
581
|
+
- Validation Failure Recovery
|
|
582
|
+
- Breaking Change Approval
|
|
583
|
+
- Phase Skip Justification
|
|
584
|
+
|
|
585
|
+
**REGRA:** Sempre forneça contexto, 2-3 opções específicas, trade-offs, e sua recomendação. Usuário decide.
|
|
586
|
+
|
|
587
|
+
---
|
|
588
|
+
|
|
55
589
|
## ESTRUTURA DO FRAMEWORK
|
|
56
590
|
|
|
57
591
|
```
|
package/README.md
CHANGED
|
@@ -34,10 +34,78 @@
|
|
|
34
34
|
|
|
35
35
|
MORPH-SPEC é um framework de desenvolvimento orientado por especificações com **30 agentes AI especializados** organizados em 4 tiers hierárquicos. Cada agente tem expertise em tecnologias específicas e segue workflows estruturados para entregar código production-ready.
|
|
36
36
|
|
|
37
|
-
**Stacks suportadas:** .NET 10/Blazor, .NET 10/Next.js
|
|
38
|
-
**Infraestrutura:** Azure Bicep (IaC)
|
|
37
|
+
**Stacks suportadas:** .NET 10/Blazor, .NET 10/Next.js, Node.js, Monorepos
|
|
38
|
+
**Infraestrutura:** Azure Bicep (IaC) + Docker
|
|
39
39
|
**Ferramenta:** Claude Code
|
|
40
40
|
**Validação:** Pipeline automático de enforcement com gates por fase
|
|
41
|
+
**Auto-Detecção:** ✨ LLM-powered context detection (v3.1+)
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## 🚀 Novidade v3.0: LLM Interaction Enhancements
|
|
46
|
+
|
|
47
|
+
MORPH-SPEC v3.0 torna o framework **explícito e orientado** para Claude Code com 8 melhorias fundamentais:
|
|
48
|
+
|
|
49
|
+
### 1. **Approval Gates** (Portões de Aprovação)
|
|
50
|
+
- ✅ Rastreamento explícito de aprovações em `state.json`
|
|
51
|
+
- 🚫 Bloqueio de transições de fase até aprovação explícita
|
|
52
|
+
- 📝 Comandos: `approve`, `reject`, `approval-status`
|
|
53
|
+
|
|
54
|
+
### 2. **Checkpoint Automation** (Validação Automática)
|
|
55
|
+
- 🔍 Auto-validação a cada 3 tasks (T003, T006, T009...)
|
|
56
|
+
- 🛡️ 4 validators: architecture, packages, security, design-system
|
|
57
|
+
- 🚧 Bloqueia progresso se falhas detectadas
|
|
58
|
+
|
|
59
|
+
### 3. **Stricter Phase Validation** (Validação Estrita)
|
|
60
|
+
- 🎯 State machine com transições válidas
|
|
61
|
+
- 📋 Validação de conteúdo (spec.md, tasks.json)
|
|
62
|
+
- 5️⃣ Sistema de 5 gates de validação
|
|
63
|
+
|
|
64
|
+
### 4. **Agent Team Spawning** (Spawning de Agentes)
|
|
65
|
+
- 🤖 Detecção automática quando spawnar (5+ agents, 15+ files, multi-domain)
|
|
66
|
+
- 🏗️ Comando `spawn-team` gera configs para Task tool
|
|
67
|
+
- 📄 Templates prontos para agent context
|
|
68
|
+
|
|
69
|
+
### 5. **Metadata Generation** (Geração de Metadados)
|
|
70
|
+
- 📊 Auto-gera `metadata.json` após cada task
|
|
71
|
+
- ⚡ Reduz uso de tokens em 60-80%
|
|
72
|
+
- 🔗 Links rápidos para spec, tasks, decisões
|
|
73
|
+
|
|
74
|
+
### 6. **Learning System** (Sistema de Aprendizado)
|
|
75
|
+
- 📚 11 patterns pré-configurados (389 linhas)
|
|
76
|
+
- 🔎 Busca: `search-patterns "{keyword}"`
|
|
77
|
+
- 📝 Captura: `capture-pattern {feature} success "Description"`
|
|
78
|
+
|
|
79
|
+
### 7. **MCP Template Enhancement** (Templates Dinâmicos)
|
|
80
|
+
- 🌐 17 placeholders com dados do projeto
|
|
81
|
+
- 📈 Injeta: files, coverage, compliance, commits
|
|
82
|
+
- 🎨 Templates: `proposal-with-mcp.md`, `spec-with-mcp.md`
|
|
83
|
+
|
|
84
|
+
### 8. **Interactive Decisions** (Decisões Estruturadas)
|
|
85
|
+
- 💬 Templates para AskUserQuestion
|
|
86
|
+
- 🎯 6 padrões documentados (scope, architecture, validation, etc.)
|
|
87
|
+
- 📖 Guia completo em `.morph/templates/decision-prompts.md`
|
|
88
|
+
|
|
89
|
+
**Configuração:** `.morph/config/llm-interaction.json` com 3 presets (strict, lightweight, no-guardrails)
|
|
90
|
+
|
|
91
|
+
**Documentação:** [docs/llm-interaction-config.md](docs/llm-interaction-config.md)
|
|
92
|
+
|
|
93
|
+
**Migration:** `npx morph-spec upgrade --preset strict`
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## ✨ Novidade v3.1: Auto-Detecção Inteligente
|
|
98
|
+
|
|
99
|
+
MORPH-SPEC agora **detecta automaticamente** o contexto do seu projeto usando Claude Code:
|
|
100
|
+
|
|
101
|
+
- 🤖 **LLM Analysis**: Analisa package.json, .csproj, README, estrutura de pastas
|
|
102
|
+
- 🎯 **90%+ Accuracy**: Few-shot learning com exemplos reais (Next.js, Blazor, Monorepo)
|
|
103
|
+
- 🔒 **Privacy-First**: Processamento local, zero chamadas externas de API
|
|
104
|
+
- 🛡️ **Secret Sanitization**: Redação automática de API keys, passwords, tokens
|
|
105
|
+
- 🧙 **Wizard Fallback**: Wizard interativo de 7 perguntas se LLM falhar
|
|
106
|
+
- ⚡ **Zero Manual Work**: Gera `.morph/project.md` e `config.json` em segundos
|
|
107
|
+
|
|
108
|
+
**Saiba mais:** [docs/cli-auto-detection.md](docs/cli-auto-detection.md)
|
|
41
109
|
|
|
42
110
|
---
|
|
43
111
|
|
|
@@ -116,13 +184,19 @@ Veja também: [Troubleshooting](#troubleshooting)
|
|
|
116
184
|
|
|
117
185
|
| Comando | Descrição |
|
|
118
186
|
|---------|-----------|
|
|
119
|
-
| `morph-spec init` | Inicializa MORPH
|
|
187
|
+
| `morph-spec init` | Inicializa MORPH e **detecta automaticamente** o contexto do projeto ✨ |
|
|
188
|
+
| `morph-spec init --wizard` | Inicializa com wizard manual (sem auto-detecção LLM) |
|
|
189
|
+
| `morph-spec init --skip-detection` | Inicializa sem detectar contexto (configuração manual) |
|
|
120
190
|
| `morph-spec init --force` | Sobrescreve instalação existente |
|
|
121
|
-
| `morph-spec update` | Atualiza projeto
|
|
191
|
+
| `morph-spec update` | Atualiza projeto e **re-analisa contexto** automaticamente ✨ |
|
|
192
|
+
| `morph-spec update --wizard` | Atualiza com wizard manual |
|
|
193
|
+
| `morph-spec update --skip-detection` | Atualiza sem re-analisar contexto |
|
|
122
194
|
| `morph-spec update --templates` | Atualiza apenas templates |
|
|
123
195
|
| `morph-spec update --standards` | Atualiza apenas standards |
|
|
124
196
|
| `morph-spec doctor` | Verifica saúde e versões da instalação |
|
|
125
197
|
|
|
198
|
+
> ✨ **Novo em v3.1+:** Auto-detecção inteligente de stack, arquitetura e infraestrutura usando Claude Code!
|
|
199
|
+
|
|
126
200
|
### Verificar Instalação
|
|
127
201
|
|
|
128
202
|
```bash
|