vireum-spec-cli 0.5.0 → 0.7.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.
@@ -0,0 +1,764 @@
1
+ "use strict";
2
+ Object.defineProperty(exports, "__esModule", { value: true });
3
+ exports.gerarClaudeSettings = gerarClaudeSettings;
4
+ exports.gerarContextInjectHook = gerarContextInjectHook;
5
+ exports.gerarPreToolGuardHook = gerarPreToolGuardHook;
6
+ exports.gerarPrePushHook = gerarPrePushHook;
7
+ exports.gerarArchitecture = gerarArchitecture;
8
+ exports.gerarMcpSetup = gerarMcpSetup;
9
+ exports.gerarRulesGlobal = gerarRulesGlobal;
10
+ exports.gerarMcpsGlobal = gerarMcpsGlobal;
11
+ exports.gerarClaudeMd = gerarClaudeMd;
12
+ exports.gerarCursorRules = gerarCursorRules;
13
+ exports.gerarDesign = gerarDesign;
14
+ exports.gerarAgentsMd = gerarAgentsMd;
15
+ function gerarClaudeSettings() {
16
+ return JSON.stringify({
17
+ hooks: {
18
+ UserPromptSubmit: [
19
+ {
20
+ matcher: '',
21
+ hooks: [
22
+ {
23
+ type: 'command',
24
+ command: '.vireum/hooks/context-inject.sh',
25
+ },
26
+ ],
27
+ },
28
+ ],
29
+ PreToolUse: [
30
+ {
31
+ matcher: 'Edit|Write',
32
+ hooks: [
33
+ {
34
+ type: 'command',
35
+ command: '.vireum/hooks/pre-tool-guard.sh',
36
+ },
37
+ ],
38
+ },
39
+ ],
40
+ },
41
+ }, null, 2);
42
+ }
43
+ function gerarContextInjectHook() {
44
+ return `#!/bin/bash
45
+ # Vireum Spec — Context Injection Hook
46
+ # Gerado por vireum-spec setup
47
+ # Injeta tasks ativas no contexto do prompt
48
+
49
+ SPEC_DIR=".spec"
50
+ ACTIVE_TASKS="\${SPEC_DIR}/tasks/active.md"
51
+
52
+ if [ -f "\$ACTIVE_TASKS" ]; then
53
+ echo ""
54
+ echo "📋 Tasks Ativas (Context Inject):"
55
+ echo "=================================="
56
+ grep "^##" "\$ACTIVE_TASKS" | head -10
57
+ echo ""
58
+ fi
59
+ `;
60
+ }
61
+ function gerarPreToolGuardHook() {
62
+ return `#!/bin/bash
63
+ # Vireum Spec — Pre-Tool Guard Hook (Soft Enforcement)
64
+ # Gerado por vireum-spec setup
65
+ # Avisa se .spec/INDEX.md não foi lido nesta sessão
66
+
67
+ INDEX_FILE=".spec/INDEX.md"
68
+ FLAG_FILE="/tmp/vireum_index_read_\$\$"
69
+
70
+ # Verificar se INDEX.md foi lido (marcado por outro hook ou ação)
71
+ if [ ! -f "\$FLAG_FILE" ] && [ -f "\$INDEX_FILE" ]; then
72
+ echo ""
73
+ echo "⚠️ AVISO: .spec/INDEX.md não foi lido nesta sessão"
74
+ echo " Leia o INDEX.md antes de implementar para entender o contexto"
75
+ echo ""
76
+ fi
77
+ `;
78
+ }
79
+ function gerarPrePushHook() {
80
+ return `#!/bin/sh
81
+ # Vireum Spec — Health Check automatico pre-push
82
+ # Gerado por vireum-spec setup
83
+
84
+ echo ""
85
+ echo " Vireum Spec — verificando consistencia do spec..."
86
+ echo ""
87
+
88
+ if command -v vireum-spec >/dev/null 2>&1; then
89
+ vireum-spec health
90
+ else
91
+ npx --no-install vireum-spec-cli health 2>/dev/null || npx -y vireum-spec-cli health
92
+ fi
93
+
94
+ STATUS=$?
95
+
96
+ if [ $STATUS -ne 0 ]; then
97
+ echo ""
98
+ echo " Spec com problemas criticos. Corrija antes de fazer push."
99
+ echo " Execute: vireum-spec health para detalhes"
100
+ echo ""
101
+ exit 1
102
+ fi
103
+
104
+ exit 0
105
+ `;
106
+ }
107
+ function gerarArchitecture(d) {
108
+ const { stack, infra, mcps, projeto } = d;
109
+ const tenant = stack.multiTenant
110
+ ? `\n## Multi-Tenancy\n- Estratégia: ${stack.tenantStrategy}\n- Nunca fazer query sem filtro de tenantId`
111
+ : '';
112
+ return `# Architecture — ${projeto}
113
+
114
+ > Atualizado via vireum-spec setup
115
+ > A IA deve registrar aqui cada decisão técnica relevante
116
+
117
+ ## Stack
118
+ - Frontend: ${stack.frontend}
119
+ - Backend: ${stack.backend}
120
+ - Banco de dados: ${stack.banco}
121
+ - ORM: ${stack.orm}
122
+ - Cache / Filas: ${stack.cache}
123
+ - Auth: ${stack.auth}
124
+ ${tenant}
125
+
126
+ ## Infraestrutura
127
+ - Hospedagem: ${infra.hospedagem}
128
+ - Containerização: ${infra.containerizacao}
129
+ - CI/CD: ${infra.cicd ? infra.cicdFerramenta : 'Não configurado'}
130
+
131
+ ## MCPs Ativos
132
+ ${mcps.map((m) => `- ${m}`).join('\n')}
133
+
134
+ ## Decisões Arquiteturais
135
+ > A IA deve registrar aqui cada decisão técnica com justificativa
136
+
137
+ | Data | Decisão | Alternativas descartadas | Motivo |
138
+ |------|---------|--------------------------|--------|
139
+ | | | | |
140
+ `;
141
+ }
142
+ function gerarMcpSetup(d) {
143
+ const mcpInfo = {
144
+ context7: 'https://github.com/upstash/context7',
145
+ github: 'https://github.com/modelcontextprotocol/servers/tree/main/src/github',
146
+ database: 'https://github.com/modelcontextprotocol/servers/tree/main/src/postgres',
147
+ browser: 'https://github.com/modelcontextprotocol/servers/tree/main/src/puppeteer',
148
+ puppeteer: 'https://github.com/modelcontextprotocol/servers/tree/main/src/puppeteer',
149
+ docker: 'https://github.com/modelcontextprotocol/servers',
150
+ redis: 'https://github.com/modelcontextprotocol/servers',
151
+ };
152
+ const lista = d.mcps
153
+ .map((m) => `### ${m}\n- Instalação: ${mcpInfo[m] || 'Ver documentação oficial'}\n- Credenciais: configurar manualmente após instalação`)
154
+ .join('\n\n');
155
+ return `# MCP Setup — ${d.projeto}
156
+
157
+ > MCPs necessários para este projeto.
158
+ > Instalação é feita manualmente — o framework não acessa credenciais.
159
+
160
+ ## MCPs do Projeto
161
+ ${lista}
162
+
163
+ ## Como instalar
164
+ 1. Acesse o link de cada MCP acima
165
+ 2. Siga as instruções de instalação
166
+ 3. Configure as credenciais manualmente no seu cliente (Claude Code / Cursor)
167
+ 4. Execute: vireum-spec verify-mcps
168
+ `;
169
+ }
170
+ function gerarRulesGlobal() {
171
+ return `# Rules — Global Vireum
172
+
173
+ > Regras globais que se aplicam a TODOS os projetos Vireum.
174
+ > Nunca editar por projeto. Em conflito com .spec/rules.md, estas prevalecem.
175
+
176
+ ## Regras de Escopo
177
+ - Nunca implementar funcionalidade fora do requirements.md sem criar task [PENDING]
178
+ - Nunca puxar task do backlog para active sem validação humana explícita
179
+ - Sempre avisar escopo creep antes de implementar — parar e perguntar
180
+
181
+ ## Regras de Planejamento
182
+ - Sempre planejar antes de implementar — escrever o que sera feito e quais arquivos serao tocados
183
+ - Confirmar o plano com o dev em tasks complexas antes de executar
184
+ - Nunca comecar a escrever codigo sem ter um plano claro
185
+
186
+ ## Regras de Design
187
+ - Sempre consultar .spec/design.md antes de criar ou modificar qualquer componente de UI
188
+ - Nunca hardcodar cores — usar sempre os tokens definidos em design.md
189
+ - Nunca misturar design systems
190
+
191
+ ## Regras de Health
192
+ - Verificar consistencia do spec no inicio de cada sessao
193
+ - Avisar o dev sobre inconsistencias antes de qualquer implementacao
194
+ - Tasks sem criterios de aceitacao devem ser sinalizadas antes de implementar
195
+
196
+ ## Regras de Spec
197
+ - Nunca marcar task como done sem validar os critérios de aceitação
198
+ - Nunca tomar decisão de arquitetura sem registrar em architecture.md com justificativa
199
+ - Sempre definir contrato de interface antes de implementar features com frontend e backend
200
+ - Ao identificar risco novo, adicionar em risks.md antes de continuar
201
+
202
+ ## Regras de Contexto
203
+ - Sempre ler INDEX.md no início de cada sessão
204
+ - Carregar outros arquivos de spec apenas quando a task exigir
205
+ - Registrar decisões relevantes em changelog.md com data
206
+
207
+ ## Regras de Tasks
208
+ - Bugs viram hotfix com tag [H] — nunca são tratados como tasks normais
209
+ - Demandas novas do cliente viram [PENDING] no backlog — nunca vão direto para active
210
+ - Task só é done quando critérios de aceitação estão validados
211
+
212
+ ## Nunca
213
+ - Implementar sem ler o spec primeiro
214
+ - Implementar sem planejar primeiro
215
+ - Criar componente de UI sem consultar design.md
216
+ - Tomar decisão de lib ou stack sem documentar o porquê
217
+ - Responder dúvida de escopo sem consultar requirements.md
218
+ - Comunicar diretamente com o cliente — isso é papel do dev
219
+ `;
220
+ }
221
+ function gerarMcpsGlobal(d) {
222
+ return `# MCPs — Global Vireum
223
+
224
+ > MCPs padrão disponíveis nos projetos Vireum.
225
+ > MCPs ativos por projeto estão em .spec/architecture.md
226
+
227
+ ## Stack Padrão
228
+ - context7 — documentação atualizada das libs (sempre ativo)
229
+ - filesystem — leitura e escrita no projeto (nativo)
230
+ - github — PRs, issues, branches referenciando tasks
231
+ - database — validar schema e dados em desenvolvimento
232
+ - browser — testar endpoints e validar fluxos
233
+ - puppeteer — testes de jornada de UI
234
+ - docker — gerenciar containers em desenvolvimento
235
+ - redis — inspecionar cache e filas (quando aplicável)
236
+
237
+ ## MCPs Ativos Neste Projeto
238
+ ${d.mcps.map((m) => `- ${m}`).join('\n')}
239
+
240
+ ## Quando usar cada MCP
241
+ - Antes de usar qualquer lib → context7: buscar docs atualizadas
242
+ - Task concluída → github: criar PR referenciando a task
243
+ - Bug identificado → github: abrir issue com contexto
244
+ - Decisão de schema → database: validar antes de implementar
245
+ - Feature implementada → browser: testar endpoint ou fluxo
246
+ - Jornada de UI → puppeteer: validar fluxo completo
247
+ `;
248
+ }
249
+ function gerarClaudeMd(d) {
250
+ const { projeto, stack, mcps } = d;
251
+ const tenant = stack.multiTenant
252
+ ? '\n- NUNCA fazer query sem filtro de tenantId — projeto multi-tenant'
253
+ : '';
254
+ const libs = [stack.frontend, stack.backend, stack.orm, stack.cache]
255
+ .filter((l) => l && l !== 'Nenhum' && l !== 'Outro')
256
+ .join(', ');
257
+ return `# ${projeto} — Vireum Spec Protocol
258
+
259
+ > Este projeto usa Spec Driven Development pela Vireum Desenvolvimento.
260
+ > Leia este arquivo completamente antes de qualquer ação.
261
+
262
+ ## Início de cada sessão
263
+ 1. Leia \`.spec/INDEX.md\` — estado atual do projeto
264
+ 2. Verifique consistencia do spec:
265
+ - tasks/active.md tem tasks sem criterios de aceitacao? → avisar o dev
266
+ - architecture.md tem stack definida? → se nao, avisar
267
+ - INDEX.md reflete o estado real do MVP? → se desatualizado, avisar
268
+ 3. Se encontrar inconsistencias criticas → avisar antes de qualquer implementacao
269
+ 4. Identifique o modo da sessão pela solicitação do dev
270
+ 5. Carregue arquivos adicionais apenas se a task exigir
271
+
272
+ ## Modos de operação
273
+
274
+ ### Modo 1 — Implementar
275
+ Acionado por: "desenvolve", "implementa", "cria", + nome de task
276
+ 1. Leia \`.spec/tasks/active.md\`
277
+ 2. Leia \`.spec/requirements.md\` para contexto da feature
278
+ 3. Consulte o Context7 para docs atualizadas da lib que vai usar
279
+ 4. Se task de UI: leia \`.spec/design.md\` antes de qualquer componente
280
+ 5. PLANEJAR: escreva o que sera implementado, quais arquivos serao tocados e riscos identificados
281
+ 6. Confirme o plano com o dev antes de executar em tasks complexas
282
+ 7. Implemente seguindo os critérios de aceitação da task
283
+ 8. Ao concluir: marque como done, mova para \`tasks/done.md\`, atualize \`INDEX.md\`
284
+ 9. Se decisão arquitetural tomada: registre em \`architecture.md\`
285
+
286
+ ### Modo 2 — Bug
287
+ Acionado por: "erro", "bug", "quebrou", "não funciona"
288
+ 1. PLANEJAR: descreva o que sera investigado e quais arquivos serao tocados
289
+ 2. Crie hotfix em \`tasks/active.md\` com tag [H] e prioridade crítica
290
+ 3. Identifique e resolva a causa raiz
291
+ 4. Registre causa raiz em \`changelog.md\`
292
+ 5. Verifique se o bug afeta outras tasks em \`tasks/active.md\`
293
+
294
+ ### Modo 3 — Nova demanda
295
+ Acionado por: "cliente pediu", "adiciona", "quero incluir" (fora do spec)
296
+ 1. Verifique se já existe em \`.spec/requirements.md\`
297
+ 2. Se não existir: crie task com tag [PENDING] em \`tasks/backlog.md\`
298
+ 3. Informe o impacto estimado e aguarde decisão do dev
299
+ 4. NUNCA implemente demanda nova sem aprovação explícita
300
+
301
+ ### Modo 4 — Dúvida de escopo
302
+ Acionado por: "como deve funcionar", "o que foi combinado", "qual o comportamento"
303
+ 1. Leia \`.spec/requirements.md\`
304
+ 2. Responda com base no spec — não invente comportamento
305
+
306
+ ## Context7 — Documentação atualizada
307
+ Sempre que for usar uma lib do projeto, consulte a documentação atualizada via Context7 antes de implementar.
308
+ Nunca assuma que você conhece a API mais recente — sempre verifique.
309
+ Libs deste projeto: ${libs}
310
+
311
+ ## Arquivos de contexto disponíveis
312
+ - Escopo e features → leia \`.spec/requirements.md\`
313
+ - Decisoes tecnicas → leia \`.spec/architecture.md\`
314
+ - Perfis e permissoes → leia \`.spec/users.md\`
315
+ - Riscos → leia \`.spec/risks.md\`
316
+ - Tarefas ativas → leia \`.spec/tasks/active.md\`
317
+ - Historico → leia \`.spec/changelog.md\`
318
+ - Design e componentes → leia \`.spec/design.md\` antes de qualquer UI
319
+
320
+ ## Regras globais
321
+ Leia \`.vireum/rules.md\` — aplicam-se a todas as sessões.
322
+
323
+ ## Regras do projeto
324
+ Leia \`.spec/rules.md\` — regras específicas deste projeto.
325
+
326
+ ## Stack
327
+ - Frontend: ${stack.frontend}
328
+ - Backend: ${stack.backend}
329
+ - Banco: ${stack.banco}
330
+ - Auth: ${stack.auth}${tenant}
331
+
332
+ ## MCPs ativos
333
+ ${mcps.map((m) => `- ${m}`).join('\n')}
334
+
335
+ ## Alertas
336
+ - Escopo creep: se a solicitação não está em requirements.md → PARAR e avisar
337
+ - Decisão de lib nova: registrar em architecture.md antes de usar
338
+ - Risco identificado: adicionar em risks.md antes de continuar
339
+ - UI sem consultar design.md → PARAR e consultar primeiro
340
+ - Spec inconsistente → avisar o dev antes de implementar
341
+ `;
342
+ }
343
+ function gerarCursorRules(d) {
344
+ return `---
345
+ description: Vireum Spec Protocol — ${d.projeto}
346
+ globs: ["**/*"]
347
+ alwaysApply: true
348
+ ---
349
+
350
+ # Vireum Spec Protocol
351
+
352
+ Este projeto usa Spec Driven Development pela Vireum Desenvolvimento.
353
+
354
+ ## Início de sessão
355
+ - Sempre leia \`.spec/INDEX.md\` primeiro
356
+ - Verifique consistencia: tasks sem criterios, stack indefinida, INDEX desatualizado
357
+ - Avise inconsistencias antes de qualquer implementacao
358
+ - Carregue outros arquivos de spec apenas quando necessário
359
+
360
+ ## Planejamento obrigatorio
361
+ Antes de qualquer implementacao:
362
+ - Escreva o que sera feito e quais arquivos serao tocados
363
+ - Identifique riscos e dependencias
364
+ - Confirme com o dev em tasks complexas antes de executar
365
+
366
+ ## Design
367
+ - SEMPRE leia \`.spec/design.md\` antes de criar ou modificar qualquer componente de UI
368
+ - Nunca hardcodar cores — usar tokens do design.md
369
+
370
+ ## Context7
371
+ - Sempre consultar Context7 antes de usar qualquer lib do projeto
372
+ - Nunca assumir que conhece a API mais recente
373
+
374
+ ## Modos
375
+ - Implementar → PLANEJAR primeiro, consulte Context7, leia tasks/active.md, se UI leia design.md
376
+ - Bug → PLANEJAR investigacao, crie hotfix [H] em active.md, registre causa raiz em changelog.md
377
+ - Nova demanda → crie [PENDING] em backlog.md, aguarde aprovação
378
+ - Dúvida de escopo → consulte requirements.md
379
+
380
+ ## Regras
381
+ - Ver \`.vireum/rules.md\` — regras globais
382
+ - Ver \`.spec/rules.md\` — regras do projeto
383
+ - Nunca implementar fora do spec sem [PENDING] aprovado
384
+ - Nunca implementar sem planejar primeiro
385
+ - Nunca criar UI sem consultar design.md
386
+ - Nunca marcar done sem critérios validados
387
+ `;
388
+ }
389
+ function gerarDesign(d) {
390
+ const { design, projeto } = d;
391
+ const sistemas = {
392
+ shadcn: {
393
+ descricao: 'Shadcn/ui com Tailwind CSS e Radix UI',
394
+ convencoes: [
395
+ 'Usar cn() para mesclar classes Tailwind',
396
+ 'Componentes em src/components/ui/',
397
+ 'Variaveis CSS em globals.css via --primary, --secondary, etc.',
398
+ 'Icones via lucide-react',
399
+ 'Formularios com react-hook-form + zod',
400
+ ],
401
+ tokens: 'Tailwind config + CSS variables',
402
+ },
403
+ tailwind: {
404
+ descricao: 'Tailwind CSS puro',
405
+ convencoes: [
406
+ 'Classes utilitarias diretamente nos componentes',
407
+ 'Cores customizadas em tailwind.config.ts',
408
+ 'Componentes em src/components/',
409
+ 'Nao criar classes CSS customizadas sem necessidade',
410
+ ],
411
+ tokens: 'tailwind.config.ts',
412
+ },
413
+ chakra: {
414
+ descricao: 'Chakra UI',
415
+ convencoes: [
416
+ 'Usar componentes do Chakra sempre que disponivel',
417
+ 'Theme customizado em src/theme/',
418
+ 'Variaveis de cor via useColorModeValue para dark/light mode',
419
+ 'Spacing seguindo escala do Chakra (1 = 4px)',
420
+ ],
421
+ tokens: 'ChakraProvider theme',
422
+ },
423
+ mui: {
424
+ descricao: 'Material UI (MUI)',
425
+ convencoes: [
426
+ 'Usar componentes MUI sempre que disponivel',
427
+ 'Theme customizado em src/theme/index.ts',
428
+ 'Usar sx prop para customizacoes pontuais',
429
+ 'Evitar inline styles — preferir theme tokens',
430
+ ],
431
+ tokens: 'createTheme()',
432
+ },
433
+ base: {
434
+ descricao: 'Design system basico gerado pelo Vireum Spec Framework',
435
+ convencoes: [
436
+ `Usar ${design.baseTailwind ? 'Tailwind CSS' : 'CSS customizado'} para estilizacao`,
437
+ 'Tokens de cor definidos neste arquivo — nunca hardcodar valores',
438
+ 'Componentes em src/components/',
439
+ 'Tipografia consistente — usar apenas as fontes definidas aqui',
440
+ 'Espacamento em multiplos de 4px',
441
+ 'Bordas arredondadas padrao: 8px',
442
+ ],
443
+ tokens: design.baseTailwind
444
+ ? 'tailwind.config.ts + CSS variables'
445
+ : 'CSS variables em globals.css',
446
+ },
447
+ custom: {
448
+ descricao: 'Design system proprio',
449
+ convencoes: ['Ver secao de convencoes abaixo'],
450
+ tokens: 'Ver secao de tokens abaixo',
451
+ },
452
+ none: {
453
+ descricao: 'Sem design system definido',
454
+ convencoes: ['A definir'],
455
+ tokens: 'A definir',
456
+ },
457
+ };
458
+ const ds = sistemas[design.system] || sistemas.none;
459
+ const coresSection = Object.keys(design.cores).filter((k) => design.cores[k]).length > 0
460
+ ? Object.entries(design.cores)
461
+ .filter(([, v]) => v)
462
+ .map(([k, v]) => `- ${k}: ${v}`)
463
+ .join('\n')
464
+ : `> Usar tokens padrao do ${ds.descricao}`;
465
+ const fontesSection = Object.keys(design.fontes).filter((k) => design.fontes[k]).length > 0
466
+ ? Object.entries(design.fontes)
467
+ .filter(([, v]) => v)
468
+ .map(([k, v]) => `- ${k}: ${v}`)
469
+ .join('\n')
470
+ : '> Usar fonte padrao do sistema';
471
+ const baseSection = design.system === 'base'
472
+ ? `
473
+ ## Espacamento
474
+ - Base: 4px
475
+ - xs: 4px | sm: 8px | md: 16px | lg: 24px | xl: 32px | 2xl: 48px
476
+
477
+ ## Bordas
478
+ - Radius padrao: 8px
479
+ - Radius pequeno: 4px
480
+ - Radius grande: 16px
481
+ - Radius pill: 9999px
482
+
483
+ ## Sombras
484
+ - sm: 0 1px 2px rgba(0,0,0,0.05)
485
+ - md: 0 4px 6px rgba(0,0,0,0.07)
486
+ - lg: 0 10px 15px rgba(0,0,0,0.10)
487
+ `
488
+ : '';
489
+ return `# Design — ${projeto}
490
+
491
+ > A IA deve consultar este arquivo antes de criar ou modificar qualquer componente de UI.
492
+ > Nunca usar cores, fontes ou espacamentos fora dos tokens definidos aqui.
493
+
494
+ ## Design System
495
+ **${ds.descricao}**
496
+ - Tokens: ${ds.tokens}
497
+
498
+ ## Cores
499
+ ${coresSection}
500
+
501
+ ## Fontes
502
+ ${fontesSection}
503
+
504
+ ## Convencoes
505
+ ${ds.convencoes.map((c) => `- ${c}`).join('\n')}
506
+ ${design.customizacoes ? `\n## Convencoes Customizadas\n${design.customizacoes}` : ''}
507
+ ${baseSection}
508
+ ## Regras para a IA
509
+ - Nunca criar componente sem consultar este arquivo primeiro
510
+ - Nunca hardcodar cores — usar sempre os tokens definidos acima
511
+ - Nunca misturar design systems — usar apenas ${ds.descricao}
512
+ - Novos componentes seguem as convencoes desta secao
513
+ - Em caso de duvida sobre UI, perguntar ao dev antes de implementar
514
+ ${design.system === 'shadcn' ? '- Sempre usar cn() para mesclar classes condicionais\n- Preferir componentes do Shadcn antes de criar do zero' : ''}
515
+ ${design.system === 'tailwind' ? '- Preferir classes Tailwind a CSS customizado\n- Nao criar novas classes sem necessidade real' : ''}
516
+ ${design.system === 'base' ? `- Seguir tokens de espacamento e bordas definidos acima\n- ${design.baseTailwind ? 'Usar classes Tailwind mapeadas para os tokens' : 'Usar CSS variables definidas em globals.css'}` : ''}
517
+
518
+ ## Componentes Existentes
519
+ > A IA deve atualizar esta secao conforme novos componentes sao criados
520
+
521
+ | Componente | Localizacao | Descricao |
522
+ |------------|-------------|-----------|
523
+ | | | |
524
+ `;
525
+ }
526
+ function gerarAgentsMd(d) {
527
+ const { projeto, stack, infra, mcps, design } = d;
528
+ const tenant = stack.multiTenant
529
+ ? `\n- **Multi-tenant:** Estratégia — ${stack.tenantStrategy}\n- **Isolamento:** Nunca fazer query sem filtro de tenantId`
530
+ : '';
531
+ const libs = [stack.frontend, stack.backend, stack.orm, stack.cache]
532
+ .filter((l) => l && l !== 'Nenhum' && l !== 'Outro')
533
+ .join(', ');
534
+ const designSection = design.system !== 'none'
535
+ ? `\n## Design System\n**${design.system === 'base' ? 'Base' : design.system.charAt(0).toUpperCase() + design.system.slice(1)}**\n${design.cores.primary ? `- Cor primária: ${design.cores.primary}` : ''}\n${design.cores.secondary ? `- Cor secundária: ${design.cores.secondary}` : ''}\n- Nunca hardcodar cores — usar sempre os tokens do design.md`
536
+ : '';
537
+ const regrasGlobaisEmbutidas = `## Regras Globais (Vireum Framework)
538
+
539
+ **Regras de Escopo**
540
+ - Nunca implementar funcionalidade fora do requirements.md sem criar task [PENDING]
541
+ - Nunca puxar task do backlog para active sem validação humana
542
+ - Sempre avisar escopo creep antes de implementar
543
+
544
+ **Regras de Planejamento**
545
+ - SEMPRE planejar antes de implementar — escrever o que será feito, quais arquivos serão tocados
546
+ - Confirmar o plano com o dev em tasks complexas antes de executar
547
+ - Nunca começar código sem plano claro
548
+
549
+ **Regras de Design**
550
+ - SEMPRE consultar design.md antes de criar ou modificar qualquer componente UI
551
+ - Nunca hardcodar cores/fontes — usar sempre os tokens definidos
552
+ - Nunca misturar design systems
553
+
554
+ **Regras de Spec**
555
+ - Nunca marcar task como done sem validar critérios de aceitação
556
+ - Nunca tomar decisão arquitetural sem registrar em architecture.md com justificativa
557
+ - Sempre definir contrato de interface antes de implementar features frontend+backend
558
+ - Ao identificar risco novo, adicionar em risks.md antes de continuar
559
+
560
+ **Regras de Contexto**
561
+ - SEMPRE ler INDEX.md no início de cada sessão
562
+ - Carregar outros arquivos de spec apenas quando a task exigir
563
+ - Registrar decisões relevantes em changelog.md com data
564
+
565
+ **Regras de Tasks**
566
+ - Bugs viram hotfix [H] — nunca tasks normais
567
+ - Demandas novas do cliente viram [PENDING] em backlog — nunca vão direto para active
568
+ - Task só é done quando critérios validados
569
+
570
+ **Nunca**
571
+ - Implementar sem ler spec primeiro
572
+ - Implementar sem planejar
573
+ - Criar UI sem consultar design.md
574
+ - Tomar decisão de lib/stack sem documentar
575
+ - Comunicar com cliente — isso é papel do dev`;
576
+ return `# ${projeto} — Vireum Spec Protocol (Agentes)
577
+
578
+ > Protocolo completo e autossuficiente para agentes (Codex CLI, Gemini CLI, ou qualquer agente).
579
+ > Documento é **first-class** — não precisa ler CLAUDE.md.
580
+
581
+ ---
582
+
583
+ ## Início de cada sessão
584
+
585
+ 1. Leia \`.spec/INDEX.md\` — estado atual do projeto e tasks ativas
586
+ 2. Verifique consistência:
587
+ - \`.spec/tasks/active.md\` tem tasks sem critérios de aceitação? → avisar
588
+ - \`.spec/architecture.md\` tem stack definida? → avisar se não
589
+ - \`.spec/INDEX.md\` reflete estado real do MVP? → avisar se desatualizado
590
+ - \`.spec/requirements.md\` tem funcionalidades mapeadas? → avisar se vago
591
+ 3. Se encontrar inconsistências → avisar o desenvolvedor ANTES de qualquer implementação
592
+ 4. Identifique o modo da sessão pela solicitação
593
+ 5. **Carregue apenas os arquivos de spec que a task exigir**
594
+
595
+ ---
596
+
597
+ ## Modos de Operação
598
+
599
+ ### Modo 1 — Implementar Feature/Task
600
+ **Acionado por:** "desenvolve", "implementa", "cria", + nome de task ou feature
601
+
602
+ 1. Leia \`.spec/tasks/active.md\` e identifique a task
603
+ 2. Leia \`.spec/requirements.md\` para entender contexto da feature
604
+ 3. Consulte **Context7** para documentação ATUALIZADA da lib que vai usar
605
+ - Nunca assuma que conhece a API mais recente
606
+ 4. **SE TASK FOR UI:** leia \`.spec/design.md\` ANTES de escrever qualquer componente
607
+ 5. **PLANEJAR:** escreva o que será implementado, quais arquivos serão tocados, riscos identificados
608
+ 6. Implemente rigorosamente segundo os **critérios de aceitação** da task
609
+ 7. Ao concluir:
610
+ - Marque task como done com validação dos critérios
611
+ - Mova para \`.spec/tasks/done.md\`
612
+ - Atualize \`.spec/INDEX.md\`
613
+ 8. Se tomou decisão arquitetural: registre em \`.spec/architecture.md\` com justificativa
614
+
615
+ ### Modo 2 — Bug / Fix Crítico
616
+ **Acionado por:** "erro", "bug", "quebrou", "não funciona", "falha"
617
+
618
+ 1. **PLANEJAR:** descreva o que será investigado, quais arquivos serão analisados
619
+ 2. Crie hotfix em \`.spec/tasks/active.md\` com tag **[H]** e prioridade crítica
620
+ 3. Identifique causa raiz (não apenas sintoma)
621
+ 4. Registre causa raiz em \`.spec/changelog.md\` com data
622
+ 5. Verifique se o bug afeta outras tasks em \`.spec/tasks/active.md\`
623
+
624
+ ### Modo 3 — Nova Demanda do Cliente
625
+ **Acionado por:** "cliente pediu", "adiciona", "quero incluir", "pode fazer"
626
+
627
+ 1. Verifique se já existe em \`.spec/requirements.md\`
628
+ 2. Se não existir: crie task com tag **[PENDING]** em \`.spec/tasks/backlog.md\`
629
+ 3. Descreva o impacto estimado (esforço, risco, dependências)
630
+ 4. **NUNCA implemente demanda nova sem aprovação explícita do dev**
631
+
632
+ ### Modo 4 — Dúvida de Escopo / Comportamento
633
+ **Acionado por:** "como deve funcionar", "qual comportamento foi combinado", "o que faz isso"
634
+
635
+ 1. Consulte \`.spec/requirements.md\` — lá está o comportamento esperado
636
+ 2. Responda **com base no spec** — não invente comportamento
637
+ 3. Se spec estiver vago: peça ao dev para clarificar em requirements.md
638
+
639
+ ---
640
+
641
+ ## Context7 — Documentação Atualizada
642
+
643
+ Quando for usar qualquer lib do projeto:
644
+ 1. Consulte **Context7** ANTES de implementar
645
+ 2. Nunca assuma que conhece a versão/API mais recente
646
+ 3. Libs deste projeto: ${libs}
647
+
648
+ ---
649
+
650
+ ## Stack Completo do Projeto
651
+
652
+ ### Frontend
653
+ - Framework: ${stack.frontend}
654
+
655
+ ### Backend
656
+ - Framework: ${stack.backend}
657
+
658
+ ### Banco de Dados
659
+ - BD: ${stack.banco}
660
+ - ORM: ${stack.orm}
661
+
662
+ ### Cache / Filas
663
+ - ${stack.cache}
664
+
665
+ ### Autenticação
666
+ - ${stack.auth}${tenant}
667
+
668
+ ### Infraestrutura
669
+ - Hospedagem: ${infra.hospedagem}
670
+ - Containerização: ${infra.containerizacao}
671
+ - CI/CD: ${infra.cicd ? infra.cicdFerramenta : 'Não configurado'}
672
+
673
+ ---
674
+
675
+ ## MCPs Ativos Neste Projeto
676
+
677
+ ${mcps.map((m) => `- **${m}** — usar para tarefas relacionadas`).join('\n')}
678
+
679
+ **Quando usar cada MCP:**
680
+ - Antes de usar qualquer lib → **context7:** buscar docs atualizadas
681
+ - Task concluída → **github:** criar PR referenciando a task
682
+ - Bug identificado → **github:** abrir issue com contexto
683
+ - Decisão de schema → **database:** validar antes de implementar
684
+ - Feature implementada → **browser:** testar endpoint ou fluxo
685
+ - Jornada de UI → **puppeteer:** validar fluxo completo
686
+
687
+ ---
688
+
689
+ ## Arquivos de Spec — Mapa Completo
690
+
691
+ | Arquivo | Propósito | Quando Ler |
692
+ |---------|-----------|-----------|
693
+ | \`.spec/INDEX.md\` | Estado atual, tasks ativas mapeadas | SEMPRE no início de sessão |
694
+ | \`.spec/requirements.md\` | Escopo completo, features MVP, Fase 2 | Antes de implementar feature |
695
+ | \`.spec/architecture.md\` | Decisões técnicas, stack, MCPs | Antes de tomar decisão arquitetural |
696
+ | \`.spec/users.md\` | Perfis de usuário, permissões, jornadas | Se task envolver acesso/permissões |
697
+ | \`.spec/risks.md\` | Riscos técnicos, compliance, mitigações | Ao identificar risco novo |
698
+ | \`.spec/tasks/active.md\` | Tasks em progresso, critérios de aceitação | Quando vai implementar |
699
+ | \`.spec/tasks/backlog.md\` | Demandas futuras, [PENDING], ideias | Quando cliente pede feature nova |
700
+ | \`.spec/tasks/done.md\` | Funcionalidades já entregues | Raramente — histórico |
701
+ | \`.spec/changelog.md\` | Histórico de decisões e causa raiz de bugs | Ao investigar ou documentar decisão |
702
+ | \`.spec/rules.md\` | Regras específicas DO PROJETO | Se task envolver lógica especial |
703
+ | \`.spec/design.md\` | Design system, cores, fontes, componentes | SEMPRE antes de criar UI${designSection} |
704
+ | \`.vireum/rules.md\` | Regras globais do Vireum Framework | Referência — aplicam-se a tudo |
705
+
706
+ ---
707
+
708
+ ## Planejamento Obrigatório (Resumo)
709
+
710
+ Antes de QUALQUER implementação, você deve:
711
+
712
+ 1. **Escrever o plano:**
713
+ - O que será feito (resumo)
714
+ - Quais arquivos serão tocados
715
+ - Quais riscos foram identificados
716
+ - Dependências externas (bibliotecas, APIs, etc)
717
+
718
+ 2. **Validar com o desenvolvedor** (em tasks complexas)
719
+ - Mostrar plano antes de começar
720
+ - Aguardar feedback/aprovação
721
+
722
+ 3. **Implementar seguindo o plano**
723
+ - Não saia do escopo da task
724
+ - Registre decisões em architecture.md
725
+ - Use os tokens de design.md (se UI)
726
+
727
+ 4. **Validar antes de marcar como done**
728
+ - Todos os critérios de aceitação foram atendidos?
729
+ - Testes passam?
730
+ - Sem regressões em outras features?
731
+
732
+ ---
733
+
734
+ ## Regras Globais — Vireum Framework
735
+
736
+ ${regrasGlobaisEmbutidas}
737
+
738
+ ---
739
+
740
+ ## Resumo Rápido
741
+
742
+ - **Pense antes de agir:** planejar é metade do trabalho
743
+ - **Leia o spec:** sempre há resposta documentada antes de você perguntar
744
+ - **Consulte Context7:** doc atualizada antes de assumir conhecimento
745
+ - **Respeite design.md:** nunca hardcode cores ou componentes
746
+ - **Registre decisões:** não é "óbvio" para o próximo — documenta
747
+ - **Valide critérios:** task só é done quando TUDO foi testado
748
+ - **Comunique com dev:** você não fala com cliente, dev fala
749
+
750
+ ---
751
+
752
+ ## Stack Resumido para Referência Rápida
753
+
754
+ **Stack:** ${[stack.frontend, stack.backend, stack.banco, stack.orm, stack.auth].filter(s => s && s !== 'Nenhum').join(' + ')}
755
+
756
+ **Design:** ${design.system}
757
+
758
+ **MCPs:** ${mcps.slice(0, 3).join(', ')}${mcps.length > 3 ? ` (+ ${mcps.length - 3} mais)` : ''}
759
+
760
+ ---
761
+
762
+ *Documento gerado por Vireum Spec. Última atualização: setup.*
763
+ `;
764
+ }