Visual Paradigm Pipeline: Um Guia Abrangente

O Visual Paradigm Pipeline é a camada de conexão centralizada entre as ferramentas de diagramação e modelagem do Visual Paradigm e o Visual Paradigm OpenDocs. Ele permite que as equipes criem ativos visuais, os armazenem como artefatos de nuvem gerenciados, acompanhem suas revisões e os incorporem em documentação viva, sem precisar exportar, fazer upload e substituir arquivos de imagem repetidamente.

O fluxo de trabalho principal é:

Criar ou gerar → Compilar no Pipeline → Incorporar no OpenDocs → Revisar alterações → Atualizar documentação

O Pipeline tem como objetivo manter diagramas e documentação sincronizados à medida que um projeto evolui. Em vez de tratar os diagramas como arquivos estáticos PNG ou JPG, ele mantém uma relação entre o visual publicado e seu ativo de origem.

1. O que o Pipeline Faz

O Pipeline executa quatro funções principais:

1. Armazenamento centralizado de ativos
   Ele armazena diagramas e outros ativos visuais em um repositório compartilhado baseado na nuvem.

2. Transição entre ferramentas
   Ele conecta o Visual Paradigm Desktop, o Visual Paradigm Online, o Chatbot de Diagramação com IA, o VPasCode e o OpenDocs.

3. Gestão de revisões
   Ele registra alterações em ativos visuais e permite que os usuários revisem revisões mais recentes ou restaurem versões anteriores.

4. Integração com documentação em tempo real
   Ele permite que ativos visuais sejam incorporados ao OpenDocs como elementos gerenciados, em vez de arquivos de imagem enviados manualmente.

Os ativos enviados pelo Pipeline podem incluir UML, BPMN, ERD, ArchiMate, fluxogramas, diagramas de arquitetura, diagramas de sequência, flipbooks e estantes de livros, dependendo da ferramenta de origem e do fluxo de publicação.

2. O Ecossistema do Pipeline

O Pipeline é mais fácil de entender como um ecossistema de três camadas.

Camada de geração

É aqui que os diagramas e modelos são criados.

• Visual Paradigm Desktop: Usado para modelagem empresarial avançada, design de banco de dados, arquitetura de software, UML, BPMN, ERD e outras tarefas profissionais de modelagem.

• Visual Paradigm Online: Usado para diagramação colaborativa baseada em navegador e planejamento visual.

• Chatbot de Diagramação com IA: Converte descrições em linguagem natural em diagramas e modelos visuais estruturados.

• VPasCode: Cria diagramas por meio de linguagens de diagramação baseadas em texto, como PlantUML, Mermaid, Markmap, Graphviz e ECharts.

O Chatbot com IA pode acelerar a criação inicial de diagramas, enquanto o VPasCode oferece uma maneira mais controlada e orientada a código para refinar e manter os diagramas.

Camada do Pipeline

O Pipeline é a camada de trânsito e gerenciamento. Ele armazena os ativos submetidos, atribui a eles uma referência identificável, rastreia as revisões e os torna disponíveis para usuários autorizados e ferramentas conectadas.

Essa camada é particularmente valiosa porque mantém a relação entre um diagrama publicado e seu modelo de origem. Quando a fonte muda, o OpenDocs pode identificar que uma revisão mais recente está disponível.

Camada de documentação

O Visual Paradigm OpenDocs é o destino para a criação de documentação de projetos, manuais técnicos, especificações de sistemas, wikis e bases de conhecimento.

Os ativos gerenciados pelo Pipeline podem ser inseridos no OpenDocs como elementos visuais ao vivo ou gerenciados. A documentação pode, portanto, conter tanto texto explicativo quanto modelos visuais vinculados que permanecem conectados à sua fonte.

3. Por que usar o Pipeline?

A documentação tradicional frequentemente segue este padrão:

1. Criar um diagrama.

2. Exportá-lo como PNG, JPG, SVG ou PDF.

3. Fazer upload para uma wiki ou documento.

4. Inserir a imagem manualmente.

5. Modificar o diagrama original posteriormente.

6. Exportá-lo novamente.

7. Substituir a imagem antiga onde quer que ela apareça.

Isso cria vários problemas:

• Podem existir múltiplas cópias do mesmo diagrama.

• A documentação pode ficar desatualizada.

• As equipes podem não saber qual revisão é a autoritativa.

• Arquivos de origem e imagens exportadas podem ficar separados.

• Metadados, relacionamentos e inteligência do modelo podem ser perdidos.

• Atualizar diagramas em vários documentos consome tempo administrativo.

O Pipeline substitui esse processo por uma conexão gerenciada entre o ativo de origem e a documentação. O resultado é uma fonte mais confiávelúnica fonte de verdadepara informações visuais.

4. Conceitos Fundamentais

Ativo gerenciado

Um ativo gerenciado é um artefato visual armazenado por meio do Pipeline, em vez de ser enviado manualmente como uma imagem comum. Ele pode ter um nome, origem, histórico de revisões e relação com um ou mais documentos.

Exemplos incluem:

• Diagramas de arquitetura de sistema

• Fluxos de jornada do usuário

• Modelos de banco de dados

• Diagramas de sequência de API

• Modelos de processos de negócios

• Roadmaps de produtos

• Diagramas organizacionais

• Livros digitais viráveis

• Estantes e coleções de conhecimento

Revisão

Uma revisão é uma versão salva de um ativo. Uma nova revisão pode ser criada quando um usuário altera um diagrama e confirma ou publica a atualização.

O histórico de revisões ajuda as equipes a:

• Ver o que foi alterado

• Identificar quem fez uma atualização

• Revisar a sequência de alterações

• Comparar os estados atual e anterior

• Restaurar uma versão anterior quando necessário

Documentação em tempo real

A documentação em tempo real contém elementos visuais que permanecem conectados a ativos de origem gerenciados. Quando um diagrama de origem é alterado, o conteúdo correspondente do OpenDocs pode indicar que uma atualização está disponível. Os autores podem então decidir quando aplicar a revisão mais recente.

Única fonte da verdade

O Pipeline reduz a incerteza sobre qual diagrama deve ser usado. Em vez de manter cópias independentes em anexos de e-mail, unidades compartilhadas, apresentações de slides e wikis, as equipes podem referenciar um ativo gerenciado centralmente.

5. Fluxo de trabalho padrão do Pipeline

Etapa 1: Criar o ativo visual

Comece com a ferramenta mais adequada para a tarefa.

Por exemplo:

• Use o Desktop para uma arquitetura empresarial detalhada.

• Use o Online para mapeamento de processos colaborativo.

• Use o Chatbot de IA para gerar um fluxo de sistema inicial a partir de uma descrição em linguagem natural.

• Use o VPasCode quando desejar uma definição de diagrama baseada em texto, semelhante a código.

Um prompt útil para a IA pode ser:

Crie um diagrama de sequência para um processo de pedido online envolvendo um cliente,
aplicação web, serviço de pagamento, serviço de estoque e banco de dados de pedidos.
Mostre cenários de pagamento bem-sucedido, falha de pagamento e estoque indisponível.

Se estiver usando o VPasCode, o resultado pode ser refinado por meio de código de diagrama. Por exemplo:

@startuml
title Fluxo de Pedido Online

ator Cliente
participante "Aplicativo Web" como Web
participante "Serviço de Pagamento" como Pagamento
participante "Serviço de Inventário" como Inventário
banco de dados "Banco de Dados de Pedidos" como DB

Cliente -> Web: Submeter pedido
Web -> Pagamento: Autorizar pagamento
Pagamento --> Web: Pagamento aprovado
Web -> Inventário: Reservar itens
Inventário --> Web: Itens reservados
Web -> DB: Criar pedido
DB --> Web: ID do pedido
Web --> Cliente: Exibir confirmação

@enduml

O VPasCode suporta fluxos de trabalho de diagramas como código, nos quais definições textuais podem ser renderizadas como diagramas visuais e refinadas antes da publicação.

Etapa 2: Revisar e refinar o ativo

Antes de comprometer um ativo no Pipeline, verifique:

• Título do diagrama

• Terminologia e rótulos

• Direção das relações

• Atores ou sistemas ausentes

• Layout e legibilidade

• Informações sensíveis ou restritas

• Se o visual corresponde ao design atual do sistema

• Se o público-alvo consegue entendê-lo

Diagramas gerados por IA devem ser revisados cuidadosamente. A IA pode acelerar a criação de diagramas, mas especialistas do domínio devem validar a arquitetura, as relações, as premissas e a terminologia.

Etapa 3: Enviar ou comprometer o ativo no Pipeline

Após revisar o diagrama, envie-o para o Pipeline usando a ação relevante de exportação, publicação, salvamento ou compromisso no aplicativo de origem.

O Pipeline, então, gerencia o ativo como um recurso de nuvem reutilizável. Dependendo do fluxo de trabalho, ele pode armazenar o ativo, atribuir-lhe uma referência identificável e registrar sua revisão inicial.

Neste ponto, as equipes devem fornecer metadados úteis, como:

• Nome claro do ativo

• Nome do projeto ou produto

• Tipo de ativo

• Proprietário

• Domínio comercial ou técnico

• Status, como Rascunho, Revisado ou Aprovado

• Descrição

• Sistema ou serviço relacionado

• Resumo da alteração

Um bom nome é:

Plataforma de Pagamentos - Fluxo de Autorização do Checkout

Um nome fraco é:

diagrama-final-v3-novo

Etapa 4: Insira o ativo no OpenDocs

No OpenDocs:

1. Abra um documento existente ou crie um novo.

2. Navegue até a seção onde o visual pertence.

3. Use o comando de inserção de ativo visual ou a opção de inserção de diagrama relevante.

4. Pesquise pelo ativo gerenciado pelo Pipeline.

5. Selecione o ativo e a revisão desejados.

6. Adicione texto explicativo ao redor.

Um diagrama raramente deve aparecer sem contexto. Inclua:

• Propósito do diagrama

• Escopo

• Premissas principais

• Atores ou componentes importantes

• Explicação de fluxos incomuns

• Data ou status de revisão

• Proprietário ou equipe responsável

Por exemplo:

Este diagrama descreve o fluxo de autorização para pagamentos com cartão.
O serviço de pagamento é responsável pela autorização, enquanto o serviço
de pedidos cria o pedido apenas após a aprovação do pagamento. Pagamentos
falhos são retornados ao aplicativo web sem criar um registro de pedido.

O ativo é incorporado como um visual gerenciado, em vez de como uma captura de tela carregada independentemente.

Etapa 5: Publique ou compartilhe a documentação

Uma vez que o documento tenha sido revisado, ele pode servir como:

• Uma especificação de requisitos de software

• Uma referência de arquitetura

• Um guia de API

• Uma wiki de projeto

• Um recurso de integração

• Um manual de treinamento

• Uma referência de conformidade ou auditoria

• Um manual de produto voltado para o cliente

O conteúdo do OpenDocs também pode ser distribuído por meio de formatos como flipbooks ou estantes de livros quando as equipes precisam de acesso estruturado e mais amplo a coleções de documentação.

Etapa 6: Atualizar o ativo de origem

Quando o sistema for alterado, atualize o diagrama em sua ferramenta de origem original.

Por exemplo, se a autenticação multifator for adicionada a um fluxo de login:

1. Abra o diagrama original no Desktop ou no VPasCode.

2. Adicione o serviço MFA e as interações relacionadas.

3. Revise o layout atualizado.

4. Salve ou envie a nova revisão para o Pipeline.

5. Adicione uma nota de alteração significativa.

Uma nota de alteração útil pode ser:

Adicionada verificação OTP entre o serviço de autenticação e o serviço MFA.
Atualizados os caminhos de falha para códigos expirados e inválidos.

Etapa 7: Revise a atualização no OpenDocs

Quando uma revisão mais recente estiver disponível, o visual vinculado no OpenDocs pode exibir um indicador de atualização. O autor do documento pode então revisar a alteração e decidir se atualiza o visual incorporado.

Essa abordagem preserva o controle editorial. A documentação não precisa necessariamente ser alterada imediatamente toda vez que um modelo de origem for editado; um autor pode revisar a revisão primeiro e aplicá-la quando apropriado.

Etapa 8: Reverter quando necessário

Se uma nova revisão introduzir um erro ou não estiver pronta para publicação, revise o histórico do ativo e restaure ou selecione uma revisão anterior, quando suportado.

A reversão é útil quando:

• Um diagrama foi atualizado prematuramente.

• Um design experimental foi enviado.

• Uma alteração introduziu relações incorretas.

• A documentação deve refletir temporariamente um estado anterior aprovado.

• Uma auditoria exige a análise de um design anterior.

6. Usando o Pipeline com Diferentes Ferramentas

Visual Paradigm Desktop

O Desktop é adequado para modelagem complexa e trabalho em escala empresarial.

Um fluxo de trabalho típico é:

1. Abra o projeto no Desktop.

2. Crie ou atualize o modelo.

3. Revise o modelo quanto à correção estrutural.

4. Envie o diagrama ou o ativo visual selecionado para o Pipeline.

5. Os usuários do OpenDocs inserem ou atualizam o ativo gerenciado.

Este fluxo de trabalho é útil para:

• Arquitetura empresarial

• Modelos UML grandes

• Engenharia de banco de dados

• Bibliotecas de processos BPMN

• Arquitetura de aplicativos

• Engenharia de sistemas

• Documentação de revisão de arquitetura

Visual Paradigm Online

O modo Online é útil quando as equipes precisam de colaboração baseada em navegador.

Um fluxo de trabalho típico é:

1. Crie um diagrama no espaço de trabalho online.

2. Convide colaboradores para revisar ou editar.

3. Finalize o diagrama.

4. Envie-o pelo Pipeline.

5. Insira-o no OpenDocs.

Isso é especialmente eficaz para:

• Planejamento de produtos

• Oficinas de processos

• Jornadas do usuário

• Colaboração em equipe

• Roadmaps

• Projeto de solução em estágio inicial

Chatbot de Diagramação com IA

O Chatbot com IA é útil para ideação rápida e rascunhos iniciais.

Um fluxo de trabalho prático é:

1. Descreva o sistema ou processo em linguagem natural.

2. Solicite um tipo específico de diagrama.

3. Revise o visual gerado.

4. Corrija a terminologia e as relações.

5. Envie o resultado pelo Pipeline.

6. Continue refinando-o no VPasCode ou Desktop, se necessário.

7. Publique-o no OpenDocs.

Para melhores resultados, especifique:

• Notação do diagrama

• Atores

• Componentes

• Relações

• Fluxos principais e alternativos

• Condições de erro

• Nível de detalhe necessário

• Público-alvo

Exemplo de prompt:

Crie um diagrama de contêiner C4 para uma plataforma de assinatura.
Inclua o portal do cliente, a API gateway, o serviço de identidade,
o serviço de faturamento, o serviço de notificação, o banco de dados PostgreSQL
e o provedor de pagamento externo. Mostre os fluxos principais de dados e
rotule cada relação com seu propósito.

Visuais gerados por IA devem ser tratados como um design inicial ou rascunho até serem revisados por um membro qualificado da equipe.

VPasCode

VPasCode é adequado para usuários que preferem Diagrama como Código.

As vantagens incluem:

• Definições de diagramas baseadas em texto

• Revisão mais fácil de alterações estruturais

• Fonte de diagrama reutilizável

• Compatibilidade com fluxos de trabalho orientados a código

• Iteração rápida

• Comparação de alterações mais clara para definições textuais

Um fluxo de trabalho comum é:

1. Gere ou escreva em PlantUML, Mermaid, Graphviz, Markmap ou outro formato suportado.

2. Renderize o diagrama.

3. Sintaxe e layout corretos.

4. Envie o visual para o Pipeline.

5. Importe ou refine-o no Desktop se for necessário um modelamento mais aprofundado.

6. Incorpore-o no OpenDocs.

O VPasCode também pode atuar como uma etapa intermediária entre ideias geradas por IA e o modelamento formal no Desktop.

7. Casos de uso comuns

Documentação de arquitetura de software

Arquitetos podem publicar diagramas de componentes, implantação, sequência e infraestrutura diretamente na documentação do sistema.

Quando um serviço é adicionado ou removido, o diagrama de origem é atualizado e a versão do OpenDocs pode ser atualizada sem substituir manualmente os arquivos de imagem.

Documentação de API

Equipes podem criar diagramas de sequência para endpoints como:

• POST /pedidos

• GET /clientes/{id}

• POST /pagamentos

• PUT /assinaturas

Cada seção de API pode incluir texto explicativo e um diagrama de interação atual. Isso ajuda os desenvolvedores a entender não apenas os parâmetros do endpoint, mas também os serviços, bancos de dados e sistemas externos envolvidos.

Requisitos de produto

Gerentes de produto podem criar fluxos de processo, jornadas do usuário, mapas de histórias e roadmaps, e incorporá-los em documentos de requisitos de produto.

Isso mantém a representação visual de um recurso alinhada com os requisitos escritos.

Gestão de processos de negócios

Analistas de negócios podem modelar processos de estado atual e de estado futuro, publicá-los no OpenDocs e manter um histórico de revisões conforme os procedimentos evoluem.

Treinamento e integração

Equipes podem combinar diagramas, explicações escritas, flipbooks e estantes de livros para criar materiais de treinamento estruturados para novos funcionários ou clientes.

Conformidade e preparação para auditoria

O Pipeline pode apoiar a rastreabilidade preservando informações de revisão e notas de mudança contextuais. As equipes podem usá-lo para mostrar como uma arquitetura, processo ou modelo de controle mudou ao longo do tempo.

O Pipeline não substitui o processo formal de governança de uma organização, mas pode fornecer evidências úteis para revisão e rastreamento histórico.

Banco de dados e arquitetura de dados

Diagramas de banco de dados e modelos de fluxo de dados podem ser incorporados ao lado de descrições de tabelas, informações de propriedade, classificações de dados e notas de integração.

8. Modelo de governança recomendado

Uma implementação bem-sucedida do Pipeline exige mais do que integração de ferramentas. As equipes devem concordar sobre como os ativos são nomeados, revisados, aprovados e atualizados.

Defina a propriedade

Atribua um proprietário a cada ativo importante.

Exemplos:

• A equipe de arquitetura empresarial é responsável pelos diagramas de arquitetura da plataforma.

• A equipe de segurança é responsável pelos diagramas de limites de confiança.

• A equipe de produto é responsável pelos mapas de jornada do cliente.

• A equipe de banco de dados é responsável pelos modelos de dados lógicos e físicos.

Estabeleça estados do ciclo de vida

Estados úteis incluem:

• Rascunho

• Em revisão

• Aprovado

• Publicado

• Descontinuado

• Arquivado

Use nomenclatura consistente

Um formato de nomenclatura padrão pode ser:

[Domínio] - [Sistema ou Processo] - [Tipo de Diagrama]

Exemplos:

Identidade - Login e MFA - Diagrama de Sequência
Comércio - Checkout - Diagrama de Atividade
Pagamentos - Autorização - Diagrama de Componente

Exija notas de alteração significativas

Toda atualização significativa deve explicar:

• O que mudou

• Por que mudou

• Quem solicitou

• Qual sistema ou requisito foi afetado

• Se documentos relacionados precisam de revisão

Separe a experimentação da publicação

Diagramas gerados por IA ou exploratórios não devem se tornar automaticamente documentação oficial. Utilize um processo de revisão antes de marcar ativos como aprovados ou publicá-los amplamente.

Revise ativos incorporados regularmente

Agende revisões com base no risco:

• Arquitetura crítica: mensalmente ou após lançamentos principais

• Diagramas de API: sempre que os contratos forem alterados

• Processos de negócio: trimestralmente ou após alterações de política

• Material de treinamento: pelo menos a cada ciclo de lançamento

• Diagramas de referência de baixo risco: anualmente

9. Padrão Prático de Documentação

Uma página OpenDocs robusta pode seguir esta estrutura:

# Fluxo de Autorização de Pagamento

## Propósito
Explica como a plataforma autoriza pagamentos com cartão antes de criar um pedido.

## Escopo
Cobre o aplicativo web, o serviço de pagamento, a triagem de fraudes,
o serviço de pedidos e o provedor de pagamento.

## Diagrama
[Ativo visual gerenciado pelo Pipeline]

## Fluxo Principal
1. O cliente envia os dados de pagamento.
2. O aplicativo web envia uma solicitação de autorização.
3. O serviço de pagamento valida a solicitação.
4. O provedor externo aprova ou rejeita o pagamento.
5. O serviço de pedidos cria um pedido após a aprovação.

## Cenários de Falha
- Dados de pagamento inválidos
- Tempo limite do provedor
- Rejeição pela triagem de fraudes
- Solicitação de autorização duplicada

## Responsabilidade
Equipe da Plataforma de Pagamento

## Histórico de Alterações
- Adicionada etapa de triagem de fraudes
- Adicionada manipulação de tempo limite do provedor
- Atualizada a sequência de criação do pedido

Este formato combina uma explicação legível por humanos com uma fonte visual gerenciada.

10. Erros Comuns a Evitar

Tratar o Pipeline como armazenamento comum de arquivos

O principal benefício não é simplesmente armazenar uma imagem na nuvem. O valor vem de manter o relacionamento com a fonte, o histórico de revisões e a conexão com a documentação.

Publicar sem revisar

Um diagrama pode estar tecnicamente correto, mas ainda assim inadequado para o público-alvo. Verifique a legibilidade, a terminologia, o escopo e os detalhes sensíveis antes da publicação.

Criar ativos duplicados

Evite enviar cópias ligeiramente diferentes do mesmo diagrama para o Pipeline com nomes pouco claros. Atualize o ativo autoritativo existente sempre que possível.

Usar notas de alteração vagas

“Diagrama atualizado” oferece pouco valor. Descreva a alteração real na arquitetura ou no processo.

Incorporar diagramas sem explicação

Um visual deve ser acompanhado de texto suficiente para que o leitor entenda seu propósito, limites e decisões importantes.

Permitir que a saída da IA se torne autoritativa automaticamente

A IA é eficaz para gerar rascunhos iniciais, mas a arquitetura, segurança, conformidade e lógica de negócios devem ser validadas por especialistas no assunto.

Ignorar indicadores de atualização de documento

Um diagrama gerenciado ainda pode ficar desatualizado se as revisões disponíveis nunca forem revisadas. Atribua responsabilidade para verificar e aplicar atualizações.

11. Medindo os Benefícios

As equipes podem avaliar o Pipeline usando medidas práticas, como:

• Tempo necessário para atualizar um diagrama em vários documentos

• Número de diagramas desatualizados encontrados durante as revisões

• Número de ativos duplicados

• Tempo gasto exportando e reenviando visuais

• Porcentagem de diagramas principais com um proprietário nomeado

• Porcentagem de páginas de documentação vinculadas a ativos aprovados

• Número de eventos de reversão ou revisão de versão

• Tempo necessário para integrar um novo membro da equipe

• Número de defeitos na documentação causados por visuais desatualizados

O resultado mais importante não é o número de diagramas armazenados. É a redução da lacuna entre o design atual do sistema e a documentação usada para entendê-lo.

12. Plano de Adoção Recomendado

Fase 1: Comece com um fluxo de trabalho

Escolha um cenário de alto valor, como:

• Documentação de arquitetura de software

• Diagramas de sequência de API

• Fluxos de requisitos do produto

• Documentação de banco de dados

Fase 2: Defina padrões

Concordar sobre:

• Convenções de nomenclatura

• Propriedade

• Notas de revisão

• Estados de revisão

• Permissões de publicação

• Responsabilidades de atualização

Fase 3: Converter documentação existente

Substitua capturas de tela frequentemente desatualizadas por ativos gerenciados pelo Pipeline. Comece com documentos que são atualizados com frequência ou usados por muitas equipes.

Fase 4: Adicionar fluxos de trabalho de IA e Diagrama como Código

Use o Chatbot de IA para ideação e VPasCode para refinamento baseado em texto. Use o Desktop quando o modelo exigir uma análise empresarial mais profunda.

Fase 5: Estabelecer revisão contínua

Inclua revisões de ativos do Pipeline em:

• Planejamento de lançamentos

• Comitês de revisão de arquitetura

• Encerramento de sprint ou iteração

• Procedimentos de gestão de mudanças

• Verificações de qualidade da documentação

Conclusão

O Pipeline Visual Paradigm transforma o gerenciamento de diagramas de uma tarefa de manipulação de arquivos em um fluxo de trabalho de documentação conectado. As equipes podem criar visuais no Desktop, Online, no Chatbot de IA ou no VPasCode; comprometê-los em um repositório centralizado; incorporá-los no OpenDocs; e atualizá-los por meio de revisões rastreadas.

Seu benefício mais importante é a continuidade. O diagrama permanece conectado à documentação, a documentação permanece mais próxima do sistema atual e as equipes gastam menos tempo exportando, recortando, fazendo upload, substituindo e procurando a versão correta.

O modelo operacional recomendado é:

Crie com cuidado, comprometa-se deliberadamente, documente com contexto, revise as revisões e publique apenas atualizações aprovadas.