Saltar al contenido principal
Esta página proporciona las plantillas oficiales para toda la documentación narrativa y orientada a tareas en el ecosistema de Lerian: descripciones generales de productos, páginas de arquitectura, guías de inicio, referencias de entidades, guías prácticas y descripciones generales de plugins. Estas plantillas reflejan la estructura y los patrones establecidos en la documentación de Midaz. Úsalas como punto de partida para cualquier página nueva. Aplica las reglas de voz y tono y capitalización independientemente de la plantilla que uses. Para documentación de endpoints de API, consulta las Plantillas de referencia de API.

​
Página de descripción general del producto

El punto de entrada para un producto o plugin. Responde tres preguntas: qué es, por qué usarlo y cómo funciona.
1

Título y subtítulo

Usa “What is [Product]?” como título. Agrega un subtítulo de una línea en el campo description del frontmatter que resuma el producto en lenguaje simple.
---
title: "What is [Product]?"
description: "[Product] does [X] for [audience]."
---
2

Párrafo de apertura

Dos a tres oraciones. Indica qué es el producto, qué hace y dónde encaja en el ecosistema de Lerian. Menciona el modelo de licencia (source-available, propietario) y enlaza al repositorio de GitHub si aplica.
Referencia: What is Midaz? abre con un solo párrafo que cubre definición del producto, licencia y disponibilidad del código fuente.
3

Por qué usar [Product]

Enmarca el problema que resuelve el producto. Usa una lista con viñetas para las propuestas de valor clave. Cada viñeta comienza con una etiqueta en negrita seguida de dos puntos y una explicación de una línea.
* **Own your ledger**: Source-available means full transparency and no vendor lock-in
* **Move fast**: Modular architecture lets you add products without re-architecting
4

Qué hace [Product]

Lista las capacidades principales como viñetas. Continúa con una subsección “Built for” si el producto sirve a audiencias distintas (fintechs, bancos, empresas).
5

Casos de uso comunes

Usa un <AccordionGroup> con 3-5 casos de uso. Cada acordeón tiene un título corto y una descripción de 2-3 oraciones del escenario.
<AccordionGroup>
  <Accordion title="Digital banking">
    Launch checking accounts, savings products, and instant transfers.
  </Accordion>
</AccordionGroup>
6

Cómo funciona [Product]

Usa un componente <Steps> para recorrer el flujo de trabajo de alto nivel (4-6 pasos). Cada paso tiene un título basado en un verbo y una explicación de 1-2 oraciones.
7

Integraciones (opcional)

Una tabla que mapea productos relacionados de Lerian con lo que agregan.
ProductIntegration
MatcherReconcile ledger transactions against external data sources
8

Próximos pasos

Un <CardGroup cols={2}> con 3-4 tarjetas que apunten a: arquitectura/conceptos, inicio rápido, casos de uso y referencia de API.
Páginas de referencia: What is Midaz? · What is CRM? · Pix in Lerian

​
Página de arquitectura y conceptos

Explica la estructura interna de un producto — sus dominios, entidades y cómo se relacionan. Esta es la página “About [Product]”.
1

Párrafo de apertura

Un párrafo que posiciona el producto arquitectónicamente. Menciona el domain-driven design si aplica.
2

Dominios o componentes

Divide el producto en sus dominios lógicos (ej., Onboarding Domain, Transaction Domain). Cada dominio obtiene un encabezado H3 con:
  • Una breve descripción de su propósito
  • Una lista con viñetas de sus componentes, cada uno con un nombre en negrita y una definición de una línea
Usa tooltips de glosario para términos específicos del dominio en su primera mención:
<GLedger>Ledger</GLedger>
3

Tabla resumen

Termina con una sección “En resumen” que contenga una tabla que mapee dominios a su propósito y APIs clave.
DomainPurposeKey APIs
OnboardingStructure and configurationOrganizations, Ledgers, Assets
Página de referencia: About Midaz

​
Página de inicio rápido

Un tutorial práctico que lleva al lector de cero a una configuración funcional. Objetivo: menos de 15 minutos.
1

Título y subtítulo

Usa “Getting started with [Product]” como título. El subtítulo debe establecer expectativas: qué logrará el lector y cuánto tiempo tomará.
2

Prerrequisitos

Una tabla listando herramientas requeridas con versiones mínimas y comandos de verificación.
ToolMinimum versionCheck command
Go1.24+go version
Agrega una <Note> para compatibilidad de SO.
3

Pasos numerados

Cada paso es un H2 con el formato “Step N — [Verbo] [objeto]” (ej., “Step 1 — Clone the repository”). Dentro de cada paso:
  • Una explicación de 1-2 oraciones de lo que hace el paso y por qué
  • Un bloque de código con el comando exacto
  • Un <Tip> o <Note> para detalles importantes (puertos, valores por defecto, detalles)
Enlaza a la referencia completa de API para cada endpoint usado:
<Tip>
  For the complete endpoint specification, see [Create an Organization](/es/reference/midaz/create-an-organization).
</Tip>
4

Paso de verificación

Siempre incluye un paso final que confirme que la configuración funciona (ej., verificar un saldo, consultar un endpoint de estado).
5

Próximos pasos

Un <CardGroup cols={2}> que apunte a entidades, transacciones, casos de uso y explorador de API.
Página de referencia: Getting started with Midaz

​
Página de referencia de entidad

Documenta una sola entidad principal (Account, Ledger, Transaction, Holder, etc.). Explica qué es, cómo se comporta y cómo usarla.
1

Definición de apertura

Un párrafo que defina la entidad, su rol en el sistema y su relación con otras entidades.
2

Conceptos principales

Explica comportamientos y reglas clave. Usa subsecciones H3 para conceptos distintos. Incluye diagramas (<Frame>) cuando las relaciones son complejas.
3

Ejemplos de código

Usa <CodeGroup> para mostrar ejemplos JSON y DSL lado a lado cuando ambos sean compatibles. Usa payloads realistas.
<CodeGroup>
   ```json JSON Example
   	{ "name": "Revenue Account", "assetCode": "BRL", "type": "deposit" }
   ```
   ```go DSL Example
   	(from @revenue :amount BRL 1000)
   ```
</CodeGroup>
4

Diagramas visuales

Usa <Frame caption="Figura N. Descripción"> para diagramas de arquitectura, flujo o relación de entidades.
5

Páginas relacionadas

Enlaza a la referencia de API, entidades relacionadas y guías relevantes.
Páginas de referencia: Transactions · Accounts · Holders

​
Página de guía

Explica cómo lograr una tarea específica o implementar un caso de uso. Orientada a tareas y contextual — explica el “por qué” junto con el “cómo”.
1

Contexto de apertura

Uno a dos párrafos que expliquen qué logrará el lector, para quién es esta guía y qué problema resuelve. Sé específico — no “aprende sobre X” sino “configura X para manejar Y.”
2

Prerrequisitos

Qué debe estar ya configurado o comprendido. Enlaza a las páginas relevantes.
3

Instrucciones paso a paso

Usa secciones H2 para las fases principales. Dentro de cada fase, usa pasos numerados o componentes <Steps>. Comienza cada paso con un verbo.Incluye:
  • Bloques de código con payloads realistas
  • <Tip> para mejores prácticas
  • <Warning> para errores comunes
  • <Note> para contexto importante
4

Verificación

Cómo el lector confirma que la tarea se completó con éxito.
5

Próximos pasos

Tarjetas o enlaces a guías relacionadas, conceptos más profundos o referencias de API.
Mantén la guía principal enfocada. Si una sección crece más allá del alcance de la tarea (análisis profundos de arquitectura, detalles de algoritmos, diseño de seguridad), muévela a una página secundaria separada y enlázala.
Páginas de referencia: Getting started with CRM · Setting up the Pix integration

​
Página de descripción general del plugin

Las descripciones generales de plugins siguen la misma estructura que las páginas de descripción general de productos, con estas adiciones:
  • Indica claramente si el plugin es source-available o propietario, y si requiere una licencia.
  • Especifica la relación de versionado con Midaz (ej., “CRM version always matches the Midaz Core version”).
  • Incluye una sección de modelo de despliegue: cómo se despliega el plugin en relación con Midaz (independientemente, mismo namespace, etc.).
  • Agrega una sección de requisitos listando lo que la institución necesita para operar el plugin (ISPB, proveedor de conectividad, madurez DevOps, etc.).
  • Si aplica, incluye una sección de compromisos y desafíos que describa honestamente las responsabilidades operativas que introduce el plugin.
Páginas de referencia: What is CRM? · Pix in Lerian · What is Fees Engine?

​
Patrones de componentes

Estos componentes de Mintlify aparecen en todas las plantillas de guías. Úsalos de manera consistente.
ComponenteCuándo usarlo
<Tip>Mejores prácticas, recomendaciones, referencias cruzadas a especificaciones de API
<Note>Contexto importante que no es una advertencia (compatibilidad de SO, valores por defecto)
<Warning>Errores comunes, cosas que causarán errores si se ignoran
<Danger>Información crítica de seguridad, riesgos de pérdida de datos, responsabilidades de cumplimiento
<Steps>Flujos de trabajo secuenciales (inicio rápido, cómo funciona)
<AccordionGroup>Casos de uso, configuraciones opcionales, detalles expandibles
<CodeGroup>Múltiples formatos de código para la misma operación (JSON + DSL, bash + YAML)
<CardGroup>Próximos pasos, páginas relacionadas
<Frame>Diagramas e ilustraciones con leyendas
Tooltips de glosarioPrimera aparición de términos específicos del dominio en una página