NOMENCLATURA DOS BLOCOS — MDS

Anatomia conceitual e visual dos 3 tipos de bloco MDS. Toda renderização (doc, site, UI de produto) usa esta nomenclatura sem variações.

A pegada modular

MDS é inspirado em blocos modulares físicos — pense LEGO™ industrial:

• Algumas peças são a fundação que todo modelo precisa (placa base sólida, conectores de origem)
• Algumas peças encaixam quando o modelo pede aquele formato específico (rodas se for veículo, asas se for avião)
• Algumas peças se empilham em cima quando o modelo cresce em complexidade (segundo andar, ornamentos, mecanismos especiais)

MDS mapeia essas 3 famílias em 3 tipos de bloco:

🟦 BLOCO-BASE

Definição

Bloco obrigatório universal. Existe em qualquer projeto descrito pelo MDS — do script de 30 linhas ao SaaS multi-tenant. N/A é proibido. Se um campo BASE não pode ser preenchido, o projeto não é descrevível pelo MDS — sintoma de que falta informação fundamental, não de que o template é grande demais.

Cor canônica

#1E40AF (azul Tailwind blue-800) — sólido, profundo, transmite “fundação que sustenta tudo”.

Visual

┌─────────────────────────────────────┐
│ 🟦 BLOCO-BASE                       │
│                                     │
│  [campo obrigatório universal]      │
│                                     │
│  ✔ preenchido com conteúdo real     │
└─────────────────────────────────────┘

Exemplos canônicos (do template)

• A1 Nome do sistema
• A2 Problema que resolve
• B1 Catálogo de atores
• C1 Catálogo de RFs
• D1 Performance esperada
• D2 Segurança
• D5 Auditabilidade (BASE Modulareasy-opinionated)
• D10 Cadastro progressivo (BASE Modulareasy-opinionated)
• G1 Stack tecnológica
• H1 Spec mínima por RF
• I1 Estratégia de testes
• I2 Critérios de aceitação
• L1 Política de entitlement (BASE Modulareasy-opinionated)
• M1 Mapa de automações cross-módulo (BASE Modulareasy-opinionated)

Total no template

18 campos / 29% do template.

Princípio operacional

“Se você não consegue preencher um BLOCO-BASE, você ainda não tem projeto — tem ideia.”

🟨 BLOCO-PLUGIN

Definição

Bloco obrigatório condicional. Tem gatilho binário S/N explícito e documentado. Se gatilho = S → preenchimento obrigatório com conteúdo real. Se gatilho = N → declaração N/A — [motivo em 1 linha] obrigatória. Omissão silenciosa é defeito de processo.

Cor canônica

#D97706 (âmbar Tailwind amber-600) — atenção, decisão, transmite “encaixe condicional”.

Visual

┌─────────────────────────────────────┐
│ 🟨 BLOCO-PLUGIN                       │
│                                     │
│  Gatilho: [pergunta binária S/N]    │
│  Resposta: S → preenchido           │
│           OU                        │
│  Resposta: N → N/A — [motivo]       │
└─────────────────────────────────────┘

Exemplos canônicos (com gatilhos)

Total no template

30 campos / 48% do template — categoria mais numerosa por design.

Princípio operacional

“Gatilho mecânico binário, nunca julgamento estético. Se você está debatendo se um PLUGIN ativa, o gatilho está mal escrito — refine o gatilho.”

Política do N/A justificado

• Formato obrigatório: N/A — [motivo em 1 linha curta]
• Bons exemplos:
  • N/A — sistema sem UI, é daemon backend puro
  • N/A — projeto single-tenant interno, sem clientes externos
  • N/A — PT-BR only, BRL only por contrato
• Maus exemplos:
  • N/A — não se aplica (vazio, não justifica)
  • N/A — talvez no futuro (futuro não é critério)
  • omitir a linha inteira (defeito)

🟩 BLOCO-STACK

Definição

Bloco incremental. Aplicável quando o projeto cresce em porte, criticidade ou complexidade. Omissão é livre, sem necessidade de justificativa formal. Preenchimento agrega valor mas não é exigido — diferente de PLUGIN, não exige N/A.

Cor canônica

#059669 (verde Tailwind emerald-600) — crescimento, expansão, transmite “empilha quando cresce”.

Visual

┌─────────────────────────────────────┐
│ 🟩 BLOCO-STACK                      │
│                                     │
│  [campo incremental]                │
│                                     │
│  ✔ preenchido (projeto cresceu até  │
│     este nível de maturidade)       │
│                                     │
│       OU                            │
│                                     │
│  ∅ omitido (sem justificativa       │
│     necessária)                     │
└─────────────────────────────────────┘

Exemplos canônicos

• B4 Jornadas secundárias
• B5 Matriz Ator × Capability
• C4 Eventos de domínio
• E3 Bounded contexts (DDD)
• E4 Aggregates + invariantes (DDD)
• F5 Catálogo de eventos pub/sub
• F6 Política de versionamento + deprecation
• G5 Diagrama de deployment
• G7 Estratégia de migração
• I7 Performance tests
• I8 Security audit
• I9 Accessibility audit
• J4 Plano de rollback
• J5 Plano de descomissionamento de legacy
• K4 Plano de incidente
• K5 Capacity planning
• L4 Marketplace de extensões
• M4 Catálogo de prompts IA

Total no template

14 campos / 23% do template.

Princípio operacional

“STACK é capacidade aspiracional. Se 80% dos seus STACK estão preenchidos, você está construindo um produto sério. Se 10%, você está construindo um MVP — válido também.”

A regra de encaixe

Toda instância MDS forma uma composição modular dos 3 tipos:

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  Projeto pequeno (script webhook):                      │
│                                                         │
│  🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦   ← 18 BASE preenchidos  │
│  🟨✔🟨✔🟨∅🟨∅🟨∅🟨∅🟨✔🟨∅...           ← 30 PLUGIN (S ou N/A) │
│  ∅∅∅∅∅∅∅∅∅∅∅∅∅∅                     ← 14 STACK omitidos │
│                                                         │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  Projeto grande (ModularHub):                           │
│                                                         │
│  🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦   ← 18 BASE preenchidos  │
│  🟨✔🟨✔🟨✔🟨✔🟨✔🟨✔🟨✔🟨✔...           ← 30 PLUGIN (quase todos S) │
│  🟩✔🟩✔🟩✔🟩✔🟩✔🟩∅🟩✔🟩✔...           ← 14 STACK (maioria sim) │
│                                                         │
└─────────────────────────────────────────────────────────┘

Mesmo template. Mesmos blocos. Composição diferente. Vocabulário invariante.

A regra de evolução

Conforme o projeto cresce ao longo do tempo:

1. BASE já está completo desde dia 1 (não há crescimento)
2. PLUGIN muda só de N/A pra preenchido (quando gatilho passa a disparar — ex: adicionou UI ao que era headless, adicionou módulo 2 ao que era monolito)
3. STACK acumula incrementalmente conforme o produto amadurece (deploys ficam mais críticos → ganha rollback; equipe cresce → ganha padrões de código; clientes ficam dependentes → ganha SLA)

MDS captura a evolução natural de qualquer produto sem reescrever a documentação — só adiciona blocos novos no topo da pilha.

A regra de visualização nominal

Em qualquer renderização (PDF, HTML, doc markdown, tela de produto):

• BLOCO-BASE sempre aparece primeiro em cada seção, com badge 🟦 ou cor #1E40AF
• BLOCO-PLUGIN aparece em sequência com badge 🟨 ou cor #D97706 e gatilho visível
• BLOCO-STACK aparece por último com badge 🟩 ou cor #059669 (ou colapsado por padrão se omitido)

Nunca renderizar PLUGIN ou STACK sem indicação visual de categoria. Nunca esconder categoria de um bloco.

Por que não usamos outras nomenclaturas

Avaliadas e descartadas:

BASE / PLUGIN / STACK ganhou porque:

1. Mantém a metáfora física de blocos modulares (LEGO industrial)
2. Cada palavra tem 1 sílaba forte → fala rápido
3. Não tem ranking implícito (“PLUGIN” não é “pior que BASE”, é função diferente)
4. Já mapeia visualmente nas cores (azul fundação, âmbar encaixe, verde extensão)
5. Funciona em PT-BR e EN-US sem tradução (palavras universais)