Página de visão geral do produto
O ponto de entrada para um produto ou plugin. Responde três perguntas: o que é, por que usar e como funciona.
Título e subtítulo
Use “What is [Product]?” como título. Adicione um subtítulo de uma linha no campo
description do frontmatter que resuma o produto em linguagem simples.Parágrafo de abertura
Duas a três frases. Declare o que o produto é, o que faz e onde se encaixa no ecossistema Lerian. Mencione o modelo de licenciamento (source-available, proprietário) e link para o repositório no GitHub se aplicável.
Por que usar [Product]
Enquadre o problema que o produto resolve. Use uma lista de bullets para as principais propostas de valor. Cada bullet começa com um rótulo em negrito seguido de dois pontos e uma explicação de uma linha.
O que [Product] faz
Liste as capacidades principais como bullets. Siga com uma subseção “Built for” se o produto atende públicos distintos (fintechs, bancos, empresas).
Casos de uso comuns
Use um
<AccordionGroup> com 3-5 casos de uso. Cada accordion tem um título curto e uma descrição de 2-3 frases do cenário.Como [Product] funciona
Use um componente
<Steps> para guiar o fluxo de trabalho de alto nível (4-6 passos). Cada passo tem um título baseado em verbo e uma explicação de 1-2 frases.Integrações (opcional)
Uma tabela mapeando produtos Lerian relacionados ao que eles adicionam.
| Produto | Integração |
|---|---|
| Matcher | Reconcilia transações do ledger contra fontes de dados externas |
Página de arquitetura e conceitos
Explica a estrutura interna de um produto — seus domínios, entidades e como se relacionam. Esta é a página “Sobre [Product]”.
Parágrafo de abertura
Um parágrafo que posiciona o produto arquiteturalmente. Mencione o domain-driven design se aplicável.
Domínios ou componentes
Divida o produto em seus domínios lógicos (ex.: Domínio de Onboarding, Domínio de Transações). Cada domínio recebe um heading H3 com:
- Uma breve descrição do seu propósito
- Uma lista de bullets dos seus componentes, cada um com um nome em negrito e uma definição de uma linha
Página de primeiros passos
Um tutorial prático que leva o leitor do zero a uma configuração funcional. Objetivo: menos de 15 minutos.
Título e subtítulo
Use “Getting started with [Product]” como título. O subtítulo deve definir expectativas: o que o leitor vai realizar e quanto tempo leva.
Pré-requisitos
Uma tabela listando ferramentas necessárias com versões mínimas e comandos de verificação.
Adicione uma
| Ferramenta | Versão mínima | Comando de verificação |
|---|---|---|
| Go | 1.24+ | go version |
<Note> para compatibilidade de SO.Passos numerados
Cada passo é um H2 com o formato “Step N — [Verbo] [objeto]” (ex.: “Step 1 — Clone the repository”). Dentro de cada passo:
- Uma explicação de 1-2 frases do que o passo faz e por quê
- Um bloco de código com o comando exato
- Uma
<Tip>ou<Note>para detalhes importantes (portas, valores padrão, pegadinhas)
Passo de verificação
Sempre inclua um passo final que confirme que a configuração funciona (ex.: verificar um saldo, consultar um endpoint de status).
Página de referência de entidade
Documenta uma única entidade principal (Account, Ledger, Transaction, Holder, etc.). Explica o que é, como se comporta e como usar.
Definição de abertura
Um parágrafo definindo a entidade, seu papel no sistema e seu relacionamento com outras entidades.
Conceitos principais
Explique comportamentos e regras-chave. Use subseções H3 para conceitos distintos. Inclua diagramas (
<Frame>) quando os relacionamentos são complexos.Exemplos de código
Use
<CodeGroup> para mostrar exemplos JSON e DSL lado a lado quando ambos forem suportados. Use payloads realistas.Diagramas visuais
Use
<Frame caption="Figura N. Descrição"> para diagramas de arquitetura, fluxo ou relacionamento de entidades.Página de guia
Explica como realizar uma tarefa específica ou implementar um caso de uso. Orientada a tarefas e contextual — explica o “porquê” junto com o “como”.
Contexto de abertura
Um a dois parágrafos explicando o que o leitor vai realizar, para quem é o guia e qual problema resolve. Seja específico — não “aprenda sobre X” mas “configure X para lidar com Y”.
Instruções passo a passo
Use seções H2 para fases principais. Dentro de cada fase, use passos numerados ou componentes
<Steps>. Comece cada passo com um verbo.Inclua:- Blocos de código com payloads realistas
<Tip>para boas práticas<Warning>para armadilhas comuns<Note>para contexto importante
Página de visão geral do plugin
Visões gerais de plugins seguem a mesma estrutura das páginas de visão geral de produto, com estas adições:
- Declare claramente se o plugin é source-available ou proprietário, e se requer uma licença.
- Especifique o relacionamento de versionamento com o Midaz (ex.: “A versão do CRM sempre corresponde à versão do Midaz Core”).
- Inclua uma seção de modelo de deploy: como o plugin é implantado em relação ao Midaz (independentemente, mesmo namespace, etc.).
- Adicione uma seção de requisitos listando o que a instituição precisa para operar o plugin (ISPB, provedor de conectividade, maturidade de DevOps, etc.).
- Se aplicável, inclua uma seção de trade-offs e desafios que descreva honestamente as responsabilidades operacionais que o plugin introduz.
Padrões de componentes
Estes componentes Mintlify aparecem em todos os templates de guias. Use-os de forma consistente.
| Componente | Quando usar |
|---|---|
<Tip> | Boas práticas, recomendações, referências cruzadas para especificações de API |
<Note> | Contexto importante que não é um aviso (compatibilidade de SO, valores padrão) |
<Warning> | Armadilhas comuns, coisas que causarão erros se ignoradas |
<Danger> | Informações críticas de segurança, riscos de perda de dados, responsabilidades de conformidade |
<Steps> | Fluxos de trabalho sequenciais (primeiros passos, como funciona) |
<AccordionGroup> | Casos de uso, configurações opcionais, detalhes expansíveis |
<CodeGroup> | Múltiplos formatos de código para a mesma operação (JSON + DSL, bash + YAML) |
<CardGroup> | Próximos passos, páginas relacionadas |
<Frame> | Diagramas e ilustrações com legendas |
| Tooltips de glossário | Primeira ocorrência de termos específicos do domínio em uma página |