Gerador de Diagramas

AÇÃO NECESSÁRIA (Execute imediatamente após a leitura)

1. NOW: Confirme se a tarefa atual se enquadra no escopo desta habilidade.
2. NOW: Leia ../tool-index.md, valide a disponibilidade da ferramenta e o caminho real.
3. NEXT: Chame o bootstrap quando a ferramenta estiver faltando, não adivinhe o caminho.
4. ACT: Entre na primeira etapa do "fluxo de trabalho" e execute, não permaneça no estado de confirmação.

Propósito

Crie diagramas claros e editáveis a partir de entradas confusas ou estruturadas. Prefira primeiro o código-fonte do diagrama baseado em texto para que o resultado possa ser revisado, versionado e refinado. Renderize para arquivos apenas quando o usuário solicitar uma imagem/PDF ou quando um artefato para download ajudar materialmente.

Fluxo de trabalho padrão

1. Identifique a intenção do usuário, o público e o material de origem.
2. Escolha a família e a linguagem do diagrama usando a tabela de decisão abaixo.
3. Normalize entidades, relacionamentos, rótulos, estados, ramificações e informações de tempo/ordem antes de escrever o código do diagrama.
4. Gere um código de diagrama conciso e legível.
5. Valide a sintaxe mentalmente e, ao criar arquivos, execute scripts/render_diagram.py.
6. Retorne o código-fonte do diagrama mais uma breve nota sobre as suposições. Ao gerar arquivos, inclua links para os arquivos de saída.

Não peça esclarecimentos em excesso. Se a solicitação for subespecificada, faça suposições razoáveis e rotule-as brevemente.

Tabela de decisão de linguagem de diagrama

Use Mermaid, a menos que outra linguagem seja claramente melhor.

Política de saída

• Sempre forneça o código-fonte editável, a menos que o usuário solicite explicitamente apenas uma imagem.
• Padrão para um único diagrama melhor. Ofereça alternativas apenas quando genuinamente úteis.
• Prefira sintaxe estável e simples em vez de recursos sofisticados que podem não renderizar em versões mais antigas do Mermaid/PlantUML.
• Use rótulos curtos. Divida textos longos em notas fora do diagrama quando necessário.
• Evite IDs de nó ambíguos. Use IDs ASCII e rótulos legíveis por humanos.
• Preserve a terminologia do usuário, mas padronize a capitalização dentro de um diagrama.
• Para diagramas técnicos, inclua limites como cliente, serviço, banco de dados, fila, API externa e operador/usuário quando eles forem implícitos.
• Para diagramas de processo de negócios, distinga o caminho feliz, pontos de decisão, falhas, novas tentativas e etapas manuais quando presentes.
• Para diagramas criados a partir de texto incerto, inclua uma seção Assumptions após o código.

Regras de geração do Mermaid

Consulte references/diagram-patterns.md para modelos compactos.

Regras gerais do Mermaid:

• Comece com a diretiva de diagrama correta, por exemplo, flowchart TD, sequenceDiagram, erDiagram, gantt, mindmap ou journey.
• Para fluxogramas, use flowchart TD, a menos que o usuário peça da esquerda para a direita; use flowchart LR para arquitetura e pipelines.
• Use subgrafos para swimlanes ou camadas de arquitetura. Nomeie subgrafos com rótulos legíveis.
• Mantenha os IDs dos nós estáveis e apenas em ASCII, por exemplo, ingest_service[Ingest Service].
• Coloque entre aspas rótulos que contêm pontuação que provavelmente confundirá o analisador.
• Use diamantes de decisão para ramificação: decision{Condition?}.
• Use rótulos de aresta consistentes: -- yes -->, -- no -->, -. async .-> ou == critical ==> apenas quando significativo.
• Em diagramas de sequência, declare participantes antes das mensagens. Use actor para humanos e participant para sistemas.

…