create-genia-os 2.4.0 → 3.0.0

package/template/.genia/development/workflows/story-development-cycle.md

@@ -1,252 +0,0 @@
-# Workflow: Story Development Cycle (SDC)
-
-> Ciclo completo de desenvolvimento de uma story, da criação ao merge.
-> Ordem: @sm → @po → @dev → @qa → @reviewer → @devops
-
----
-
-## Visão Geral
-
-O Story Development Cycle (SDC) é o coração do GEN.IA OS. Cada story percorre um ciclo rigoroso de criação, validação, desenvolvimento, revisão e entrega. Nenhuma etapa pode ser pulada. O SDC garante rastreabilidade completa de cada funcionalidade entregue.
-
-**Duração típica:** 1-5 dias por story (dependendo do tamanho)
-**Pré-requisito:** Spec Pipeline concluído (PRD.md + SPEC-TECNICO.md aprovados)
-
----
-
-## Estados da Story
-
-```
-Draft → Ready → InProgress → InQA → InReview → InPR → Done
-```
-
-| Estado | Responsável | Significado |
-|--------|-------------|-------------|
-| Draft | @sm | Story criada, aguardando validação |
-| Ready | @po | Story validada, pronta para sprint |
-| InProgress | @dev | Em desenvolvimento |
-| InQA | @qa | Em revisão de qualidade |
-| InReview | @reviewer | Em code review |
-| InPR | @devops | PR criado, aguardando merge |
-| Done | @po | Story aceita e entregue |
-
----
-
-## Fase 1 — Draft (@sm)
-
-**Responsável:** Sami (@sm)
-**Input:** Épico do PRD + SPEC-TECNICO para contexto técnico
-**Output:** `docs/stories/STORY-XXX.md` em status Draft
-
-### O que acontece:
-1. @sm identifica próxima story a ser criada com base no backlog priorizado por @po
-2. Cria o arquivo STORY-XXX.md seguindo o template padrão
-3. Escreve a User Story no formato correto
-4. Define mínimo 3 Acceptance Criteria mensuráveis e testáveis
-5. Documenta o não-escopo explicitamente
-6. Adiciona notas técnicas relevantes do SPEC-TECNICO
-7. Estima esforço (P/M/G/XG)
-
-### Critérios de saída:
-- [ ] STORY-XXX.md criado com template completo
-- [ ] User Story no formato "Como... quero... para..."
-- [ ] Mínimo 3 ACs mensuráveis
-- [ ] Não-escopo documentado
-- [ ] Épico pai referenciado
-- [ ] Status: Draft
-
-**→ Passa para @po**
-
----
-
-## Fase 2 — Validate (@po)
-
-**Responsável:** Pax (@po)
-**Input:** `docs/stories/STORY-XXX.md` em Draft
-**Output:** Story aprovada (Ready) ou devolvida para revisão
-
-### O que acontece:
-1. @po executa checklist de validação 10-point
-2. Se aprovada: altera status para Ready e define prioridade no sprint
-3. Se reprovada: devolve para @sm com feedback específico e items a corrigir
-4. @sm ajusta e resubmete (sem limite de tentativas nesta fase)
-
-### Critérios de aprovação (10-point checklist):
-- [ ] Formato correto: "Como [persona], quero [ação], para [benefício]"
-- [ ] Persona identificada e definida no PRD
-- [ ] Valor explícito e mensurável
-- [ ] Mínimo 3 ACs, todos testáveis
-- [ ] Independente ou dependências mapeadas
-- [ ] Tamanho adequado para uma sprint
-- [ ] Estimável com as informações disponíveis
-- [ ] Não-escopo explícito
-- [ ] Épico pai identificado
-- [ ] DoD aplicável à story
-
-**Score mínimo: 9/10**
-
-**→ Status muda para Ready**
-
----
-
-## Fase 3 — Ready (@po + @sm)
-
-**Responsável:** @po (prioridade) + @sm (sprint)
-**Status:** Ready
-
-A story está validada e entra no sprint backlog. @sm inclui na sprint planning e atribui ao @dev. Nenhum desenvolvimento começa sem story em Ready.
-
----
-
-## Fase 4 — Develop (@dev)
-
-**Responsável:** Dev (@dev)
-**Input:** `docs/stories/STORY-XXX.md` em Ready + SPEC-TECNICO.md
-**Output:** Código implementado, testes escritos, commits locais
-
-### O que acontece:
-1. @dev lê completamente a story e o SPEC-TECNICO
-2. Cria o branch: `git checkout -b feat/STORY-XXX-descricao`
-3. Implementa o código seguindo os padrões arquiteturais
-4. Escreve testes unitários (coverage >= 80%)
-5. Executa lint, typecheck e testes localmente
-6. Comita com mensagem formatada (nunca faz push — exclusivo de @devops)
-7. Atualiza status da story para InProgress
-8. Ao concluir, notifica @qa
-
-### Critérios de saída:
-- [ ] Todos os ACs implementados
-- [ ] Testes unitários escritos (coverage >= 80%)
-- [ ] Lint passando sem warnings
-- [ ] Typecheck passando
-- [ ] Commits atômicos e bem descritos
-- [ ] Status: InQA
-
-**→ Passa para @qa**
-
----
-
-## Fase 5 — QA Review (@qa)
-
-**Responsável:** Quinn (@qa)
-**Input:** Branch com código implementado
-**Output:** Relatório QA — APROVADO ou REPROVADO com bugs
-
-### O que acontece:
-1. @qa verifica cada Acceptance Criterion da story
-2. Executa testes (unitários, integração se houver)
-3. Verifica casos de borda e cenários negativos
-4. Documenta bugs encontrados com severidade
-5. Emite veredicto: APROVADO ou REPROVADO
-
-**QA Loop (máximo 5 iterações):**
-```
-@qa revisa → REPROVADO → @dev corrige → @qa re-revisa → ...
-```
-
-Se após 5 iterações ainda reprovado: escalar para @architect + @pm
-
-### Critérios de aprovação:
-- [ ] Todos os ACs verificados e passando
-- [ ] Zero bugs CRÍTICOS
-- [ ] Máximo 2 bugs ALTOS (documentados para correção futura)
-- [ ] Testes passando (>= 80% coverage)
-- [ ] Lint sem warnings
-- [ ] Status: InReview
-
-**→ Passa para @reviewer**
-
----
-
-## Fase 6 — Code Review (@reviewer)
-
-**Responsável:** Rev (@reviewer)
-**Input:** Branch aprovado pelo @qa
-**Output:** LGTM (aprovado) ou mudanças solicitadas
-
-### O que acontece:
-1. @reviewer lê o diff completo da story
-2. Verifica corretude, arquitetura, segurança, legibilidade
-3. Emite aprovação (LGTM) ou lista de mudanças bloqueantes
-4. @dev corrige mudanças bloqueantes e notifica @reviewer
-5. @reviewer re-aprova
-
-### Critérios de aprovação:
-- [ ] Sem issues de segurança
-- [ ] Arquitetura consistente com SPEC-TECNICO
-- [ ] Imports absolutos usados
-- [ ] Código legível e manutenível
-- [ ] Testes de qualidade (testam comportamento, não implementação)
-- [ ] Status: InPR
-
-**→ Passa para @devops**
-
----
-
-## Fase 7 — Push e PR (@devops)
-
-**Responsável:** Gate (@devops)
-**Input:** Branch aprovado por @qa e @reviewer
-**Output:** PR criado no repositório remoto
-
-### O que acontece:
-1. @devops verifica checklist pré-push
-2. Faz `git push -u origin feat/STORY-XXX-descricao`
-3. Cria Pull Request com template completo
-4. Atribui reviewers para merge
-5. Monitora CI/CD pipeline
-6. Faz merge após aprovação do PR e CI verde
-
-### Critérios de saída:
-- [ ] Push realizado sem erros
-- [ ] PR criado com descrição completa
-- [ ] CI/CD pipeline verde
-- [ ] PR mergeado para main
-- [ ] Status: Done
-
----
-
-## Fase 8 — Done (@po)
-
-**Responsável:** Pax (@po)
-**Output:** Story marcada como Done, backlog atualizado
-
-### O que acontece:
-1. @po verifica que todos os ACs foram entregues conforme especificado
-2. Aceita a story formalmente (marca como Done)
-3. Atualiza o backlog
-4. Informa @pm sobre o progresso do épico
-
----
-
-## Diagrama do Fluxo
-
-```
-@sm cria story (Draft)
-       ↓
-@po valida (Ready) ←── @sm corrige ──← REPROVADO
-       ↓
-@dev implementa (InProgress)
-       ↓
-@qa revisa (InQA) ←── @dev corrige ──← REPROVADO (max 5x)
-       ↓
-@reviewer revisa (InReview) ←── @dev corrige ──← CHANGES
-       ↓
-@devops push + PR (InPR)
-       ↓
-@po aceita (Done)
-```
-
----
-
-## Regras Invioláveis do SDC
-
-1. Nunca pular a validação de @po — story não-validada não pode ser desenvolvida
-2. @dev nunca faz push — exclusivo de @devops
-3. QA Loop tem máximo 5 iterações — após isso, escalar
-4. Code review é obrigatório antes do push — sem exceção
-5. Story só vai para Done quando @po aceitar formalmente
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/guidelines/clean-code.md

@@ -1,98 +0,0 @@
-# Guideline: Clean Code
-
-> Padroes de codigo pragmaticos - conciso, direto, sem over-engineering.
-
-## Principios Core
-
-| Principio | Regra |
-|-----------|-------|
-| **SRP** | Single Responsibility - cada funcao/classe faz UMA coisa |
-| **DRY** | Don't Repeat Yourself - extrair duplicatas, reusar |
-| **KISS** | Keep It Simple - solucao mais simples que funciona |
-| **YAGNI** | You Aren't Gonna Need It - nao construir features nao usadas |
-| **Boy Scout** | Deixar codigo mais limpo do que encontrou |
-
-## Regras de Naming
-
-| Elemento | Convencao |
-|----------|-----------|
-| **Variaveis** | Revelar intencao: `userCount` nao `n` |
-| **Funcoes** | Verbo + substantivo: `getUserById()` nao `user()` |
-| **Booleans** | Forma de pergunta: `isActive`, `hasPermission`, `canEdit` |
-| **Constantes** | SCREAMING_SNAKE: `MAX_RETRY_COUNT` |
-
-> **Regra:** Se voce precisa de um comentario para explicar o nome, renomeie.
-
-## Regras de Funcao
-
-| Regra | Descricao |
-|-------|-----------|
-| **Pequena** | Max 20 linhas, idealmente 5-10 |
-| **Uma Coisa** | Faz uma coisa, faz bem |
-| **Um Nivel** | Um nivel de abstracao por funcao |
-| **Poucos Args** | Max 3 argumentos, preferir 0-2 |
-| **Sem Side Effects** | Nao mutar inputs inesperadamente |
-
-## Estrutura de Codigo
-
-| Padrao | Aplicar |
-|--------|---------|
-| **Guard Clauses** | Early returns para edge cases |
-| **Flat > Nested** | Evitar nesting profundo (max 2 niveis) |
-| **Composicao** | Funcoes pequenas compostas |
-| **Colocacao** | Manter codigo relacionado proximo |
-
-## Estilo de Codigo AI
-
-| Situacao | Acao |
-|----------|------|
-| Usuario pede feature | Escrever diretamente |
-| Usuario reporta bug | Corrigir, nao explicar |
-| Requisito nao claro | Perguntar, nao assumir |
-
-## Anti-Patterns
-
-| NAO Fazer | Fazer |
-|-----------|-------|
-| Comentar cada linha | Deletar comentarios obvios |
-| Helper para one-liner | Inline o codigo |
-| Factory para 2 objetos | Instanciacao direta |
-| utils.ts com 1 funcao | Colocar onde usado |
-| "First we import..." | Apenas escrever codigo |
-| Deep nesting | Guard clauses |
-| Magic numbers | Named constants |
-| God functions | Dividir por responsabilidade |
-
-## Antes de Editar Qualquer Arquivo
-
-| Pergunta | Por que |
-|----------|---------|
-| **O que importa este arquivo?** | Pode quebrar |
-| **O que este arquivo importa?** | Mudanca de interface |
-| **Quais testes cobrem isso?** | Testes podem falhar |
-| **E um componente compartilhado?** | Multiplos lugares afetados |
-
-> **Regra:** Editar arquivo + todos dependentes na MESMA tarefa.
-
-## Self-Check Antes de Completar
-
-| Check | Pergunta |
-|-------|----------|
-| **Objetivo alcancado?** | Fiz exatamente o que usuario pediu? |
-| **Arquivos editados?** | Modifiquei todos arquivos necessarios? |
-| **Codigo funciona?** | Testei/verifiquei a mudanca? |
-| **Sem erros?** | Lint e TypeScript passam? |
-| **Nada esquecido?** | Algum edge case perdido? |
-
-## Resumo
-
-| Fazer | Nao Fazer |
-|-------|-----------|
-| Escrever codigo direto | Escrever tutoriais |
-| Deixar codigo se auto-documentar | Adicionar comentarios obvios |
-| Corrigir bugs imediatamente | Explicar o fix primeiro |
-| Inline coisas pequenas | Criar arquivos desnecessarios |
-| Nomear coisas claramente | Usar abreviacoes |
-| Manter funcoes pequenas | Escrever funcoes 100+ linhas |
-
-> **Lembrar: O usuario quer codigo funcionando, nao uma aula de programacao.**

package/template/.genia/guidelines/testing.md

@@ -1,176 +0,0 @@
-# Guideline: Testing Patterns
-
-> Principios para suites de teste confiaveis.
-
-## Piramide de Testes
-
-```
-        /\          E2E (Poucos)
-       /  \         Fluxos criticos
-      /----\
-     /      \       Integration (Alguns)
-    /--------\      API, DB queries
-   /          \
-  /------------\    Unit (Muitos)
-                    Funcoes, classes
-```
-
-## Padrao AAA
-
-| Etapa | Proposito |
-|-------|-----------|
-| **Arrange** | Configurar dados de teste |
-| **Act** | Executar codigo sob teste |
-| **Assert** | Verificar resultado |
-
-## Selecao de Tipo de Teste
-
-| Tipo | Melhor Para | Velocidade |
-|------|-------------|------------|
-| **Unit** | Funcoes puras, logica | Rapido (<50ms) |
-| **Integration** | API, DB, servicos | Medio |
-| **E2E** | Fluxos criticos do usuario | Lento |
-
-## Principios de Unit Test
-
-### Bons Unit Tests (FIRST)
-
-| Principio | Significado |
-|-----------|-------------|
-| Fast | < 100ms cada |
-| Isolated | Sem deps externos |
-| Repeatable | Mesmo resultado sempre |
-| Self-checking | Sem verificacao manual |
-| Timely | Escritos com o codigo |
-
-### O Que Testar
-
-| Testar | Nao Testar |
-|--------|------------|
-| Business logic | Codigo do framework |
-| Edge cases | Libs de terceiros |
-| Error handling | Getters simples |
-
-## Principios de Integration Test
-
-### O Que Testar
-
-| Area | Foco |
-|------|------|
-| API endpoints | Request/response |
-| Database | Queries, transactions |
-| External services | Contratos |
-
-### Setup/Teardown
-
-| Fase | Acao |
-|------|------|
-| Before All | Conectar recursos |
-| Before Each | Resetar estado |
-| After Each | Limpar |
-| After All | Desconectar |
-
-## Principios de Mocking
-
-### Quando Fazer Mock
-
-| Mock | Nao Mock |
-|------|----------|
-| External APIs | Codigo sob teste |
-| Database (unit) | Dependencias simples |
-| Time/random | Funcoes puras |
-| Network | Stores in-memory |
-
-### Tipos de Mock
-
-| Tipo | Uso |
-|------|-----|
-| Stub | Retornar valores fixos |
-| Spy | Rastrear chamadas |
-| Mock | Definir expectativas |
-| Fake | Implementacao simplificada |
-
-## Organizacao de Testes
-
-### Naming
-
-| Padrao | Exemplo |
-|--------|---------|
-| Should behavior | "should return error when..." |
-| When condition | "when user not found..." |
-| Given-when-then | "given X, when Y, then Z" |
-
-### Agrupamento
-
-| Nivel | Uso |
-|-------|-----|
-| describe | Agrupar testes relacionados |
-| it/test | Caso individual |
-| beforeEach | Setup comum |
-
-## Dados de Teste
-
-### Estrategias
-
-| Abordagem | Uso |
-|-----------|-----|
-| Factories | Gerar dados de teste |
-| Fixtures | Datasets predefinidos |
-| Builders | Criacao fluente de objetos |
-
-### Principios
-- Usar dados realistas
-- Randomizar valores nao essenciais (faker)
-- Compartilhar fixtures comuns
-- Manter dados minimos
-
-## Best Practices
-
-| Pratica | Por que |
-|---------|---------|
-| Um assert por teste | Razao clara de falha |
-| Testes independentes | Sem dependencia de ordem |
-| Testes rapidos | Rodar frequentemente |
-| Nomes descritivos | Auto-documentacao |
-| Limpar | Evitar side effects |
-
-## Anti-Patterns
-
-| NAO Fazer | Fazer |
-|-----------|-------|
-| Testar implementacao | Testar comportamento |
-| Duplicar codigo de teste | Usar factories |
-| Setup complexo | Simplificar ou dividir |
-| Ignorar testes flaky | Corrigir causa raiz |
-| Pular cleanup | Resetar estado |
-
-## Exemplo de Teste
-
-```typescript
-describe('UserService', () => {
-  describe('createUser', () => {
-    it('should create user with valid data', async () => {
-      // Arrange
-      const userData = { name: 'John', email: 'john@test.com' };
-
-      // Act
-      const user = await userService.createUser(userData);
-
-      // Assert
-      expect(user.id).toBeDefined();
-      expect(user.name).toBe('John');
-    });
-
-    it('should throw error when email is invalid', async () => {
-      // Arrange
-      const userData = { name: 'John', email: 'invalid' };
-
-      // Act & Assert
-      await expect(userService.createUser(userData))
-        .rejects.toThrow('Invalid email');
-    });
-  });
-});
-```
-
-> **Lembrar:** Testes sao documentacao. Se alguem nao consegue entender o que o codigo faz pelos testes, reescreva-os.

package/template/.genia/skills/design/canvas-design.md

@@ -1,109 +0,0 @@
-# Skill: /canvas-design
-
-## Metadata
-- **Nome**: Canvas Design
-- **Comando**: /canvas-design
-- **Agente**: @dev
-- **Categoria**: design
-- **Versao**: 2.0
-
-## Descricao
-Criar arte visual bonita em .png e .pdf usando filosofia de design. Criar designs visuais originais para posters, pecas de arte e designs estaticos.
-
-## Quando Usar
-- Criar posters
-- Criar pecas de arte
-- Criar designs estaticos
-- Criar material visual para apresentacoes
-
-## Processo em Duas Etapas
-
-### 1. Criacao da Filosofia de Design (.md)
-### 2. Expressao no Canvas (.pdf ou .png)
-
-## Filosofia de Design
-
-### Nomear o Movimento (1-2 palavras)
-Exemplos:
-- "Brutalist Joy"
-- "Chromatic Silence"
-- "Metabolist Dreams"
-
-### Articular a Filosofia (4-6 paragrafos)
-Expressar como a filosofia se manifesta atraves de:
-- Espaco e forma
-- Cor e material
-- Escala e ritmo
-- Composicao e equilibrio
-- Hierarquia visual
-
-### Diretrizes Criticas
-- **Evitar redundancia**: Cada aspecto mencionado uma vez
-- **Enfatizar craftsmanship**: O trabalho deve parecer meticulosamente elaborado
-- **Deixar espaco criativo**: Especifico mas conciso
-
-## Exemplos de Filosofia
-
-### "Concrete Poetry"
-Comunicacao atraves de forma monumental e geometria bold. Blocos de cor massivos, tipografia escultural, divisoes espaciais brutalistas. Energia de poster polones encontra Le Corbusier.
-
-### "Chromatic Language"
-Cor como sistema primario de informacao. Precisao geometrica onde zonas de cor criam significado. Tipografia minimal - pequenas labels sans-serif.
-
-### "Analog Meditation"
-Contemplacao visual quieta atraves de textura e espaco respirando. Grao de papel, bleeds de tinta, vasto espaco negativo. Estetica de photobook japones.
-
-### "Geometric Silence"
-Ordem pura e contencao. Precisao baseada em grid, fotografia bold ou graficos stark, espaco negativo dramatico. Formalismo suico encontra honestidade material brutalista.
-
-## Criacao do Canvas
-
-### Principios
-- Trabalho de qualidade de museu ou revista
-- Padroes repetitivos e formas perfeitas
-- Tratamento como um diagrama de disciplina imaginaria
-- Tipografia esparsa e clinica
-- Paleta de cores limitada e intencional
-
-### Texto como Elemento Visual
-- Texto sempre minimal e visual-first
-- Contexto guia a escala
-- Sofisticacao nao-negociavel
-- Usar fontes do diretorio `./canvas-fonts`
-
-### Qualidade
-- Parecer que levou incontaveis horas para criar
-- Alguem no topo absoluto da sua area
-- Cuidado meticuloso em cada detalhe
-- Nada sobrepoe, formatacao impecavel
-
-## Output
-
-- Arquivo .md com a filosofia de design
-- Arquivo .pdf ou .png com o canvas final
-
-## Segunda Passagem (Refinamento)
-
-**CRITICO**: Ao refinar:
-- NAO adicionar mais graficos
-- Refinar o que ja foi criado
-- Tornar extremamente crisp
-- Respeitar filosofia de design
-- Respeitar principios de minimalismo
-
-## Multi-Paginas
-
-Quando solicitado multiplas paginas:
-- Criar paginas criativas na mesma linha da filosofia
-- Cada pagina distintamente diferente
-- Bundlar no mesmo .pdf ou multiplos .pngs
-- Tratar como um livro de mesa de cafe
-- Paginas como twists e memorias do original
-
-## Tasks Relacionadas
-- task:criar-poster
-- task:criar-arte-visual
-- task:design-grafico
-
-## Workflows
-- workflow:criacao-material-visual