Pular para o conteúdo principal

MDS · Modular Development Style

Glossário

Termos canônicos do MDS — definições oficiais para evitar ambiguidade.

GLOSSÁRIO — MDS

Termos canônicos da Modular Development Style. Ordem alfabética.

A

  • Anti-pattern — Padrão proibido em projeto MDS. Lista canônica de 12 no Manifesto.
  • Artefato — Documento físico (markdown, HTML, PDF) que renderiza uma instância MDS. README, PRD, DRS, etc.
  • Artefatos-companheiros (família de 5) — Ver Família de 5.

B

  • BLOCO — Unidade canônica do template. Cada um dos 86 campos é um bloco.
  • BLOCO-BASE 🟦 — Bloco obrigatório universal. N/A não aceito. Cor #1E40AF.
  • BLOCO-PLUGIN 🟨 — Bloco condicional. Gatilho binário S/N. N/A obrigatório se gatilho = N. Cor #D97706.
  • BLOCO-STACK 🟩 — Bloco incremental. Omissão livre sem justificativa. Cor #059669.
  • Bloco macro — Agrupamento de campos relacionados. 15 ao todo (0 + A–N).
  • Bloco 0 (Elicitação e Discovery) — bloco pré-spec, adicionado 2026-05-27. Garante que o problema foi entendido antes de descrever a solução. Precede o Bloco A.
  • Bloco N (Feedback Loop Pós-Deploy) — bloco pós-deploy, adicionado 2026-05-27. Fecha o ciclo MDS: observação em produção retroalimenta a especificação. Sucede o Bloco M.

C

  • Cadastro progressivo — Princípio canônico (BASE D10): só identificador obrigatório, demais campos NULL. Sistema USA quando preenchido, AUSÊNCIA nunca bloqueia.
  • Composição modular — Conjunto de blocos preenchidos numa instância. Mesmo template, composição diferente.

D

  • DRS — Documento de Requisitos de Software. Artefato central do MDS (15 blocos / 86 campos). NÃO é entregue sozinho: gera os 4 companheiros padrão (ver Família de 5).

E

  • Entidade do MDS — A quem pertence o MDS, define identidade visual e caminho de publicação. Cliente direto (Modulareasy, em /mds/<slug>) ou cliente indireto de parceiro (em /mds/<parceiro>/<slug>, white-label com a IDV do parceiro). Pergunta-se ao iniciar.
  • Entitlement — Princípio canônico (BASE L1): toda funcionalidade liga/desliga via UI de admin em runtime. Sem hardcode.

F

  • Fase 0 / Planejamento — A fase que abre o Roadmap de Implementação. Contém 28 cards com prefixo P0-, todos marcados como concluídos na aprovação do DRS, tornando visível o trabalho de elicitação, especificação, geração dos companheiros e aprovação. Corresponde à seção Planejamento do progresso em 3 seções (peso 40%); faz o projeto nascer em 40% em vez de 0%. (Cravado 2026-07.)

  • Família de 5 — Padrão de entrega do MDS: um DRS aprovado gera, junto, 4 companheiros — o Roadmap de Implementação (que abre com a Fase 0 de Planejamento, já concluída), o Inventário de Artefatos, as Jornadas dos Atores e o Plano de Testes (Alfa e Beta). Os 5 cruzam-se. O progresso do projeto tem 3 seções de peso fixo 40/40/20 (Planejamento, Construção, Testes). Entregar só o DRS é entrega incompleta. (Cravado 2026-06; Testes e Fase 0 em 2026-07.)

G

  • Gatilho — Pergunta binária S/N que ativa um BLOCO-PLUGIN. Mecânico, não subjetivo.

I

  • IA-gen — Botão “Gerar com IA” first-class. Princípio Modulareasy (M2).
  • Instância — Aplicação concreta do template MDS num projeto específico.
  • Inventário de Artefatos — Companheiro do DRS (doc_kind=inventory): registro verificável de tudo que precisa ser criado (funis, automações, tags, campos, integrações…), por tipo, cada item com Para que serve / Relacionado com / Onde fica. Responde “criei todos?”.

J

  • Jornadas dos Atores — Companheiro do DRS (doc_kind=journeys): texto que descreve como cada papel opera o sistema, função a função (Como entra / Onde entra / O que faz), genérico e sem nomes próprios.

M

  • MDS — Modular Development Style. Esta metodologia.
  • Modulareasy-opinionated — Campo cuja categoria reflete convicção Modulareasy. Modulareasy trata como BASE, terceiros podem tratar como PLUGIN. (D5, D10, L1, M1)

N

  • N/A justificado — Declaração formal de uma linha indicando motivo da omissão de um PLUGIN. Obrigatório quando gatilho = N.

P

  • PLUGIN — Ver BLOCO-PLUGIN.
  • Plano de Testes — Companheiro do DRS (doc_kind=tests): checklist de validação em duas seções — Alfa (interno, um item por RF usando o H1, mais testes gerais de visual/segurança/performance/mobile/regressão) e Beta (com o cliente e usuários reais, um item por jornada, mais coleta de feedback). Corresponde à seção Testes do progresso em 3 seções (peso 20%). (Cravado 2026-07.)
  • PRD — Product Requirements Document. Tipo de artefato MDS de tier médio.
  • Princípio — Um dos 7 princípios do MANIFESTO. Inviolável.

R

  • Roadmap de Implementação — Companheiro do DRS (doc_kind=roadmap): a fila de construção verificável; cada RF vira tarefa, em sequência por onda, orientada a verificação-primeiro (TDD), em card com o que implementar, como verificar e o aceite (H1).

S

  • Sistema trabalha pra você — Princípio canônico (BASE M1): cada bloco responde “o que automatiza? que evento dispara? onde cabe IA-gen? que dados pode CONSUMIR?”.
  • STACK — Ver BLOCO-STACK.

T

  • Template — Conjunto canônico dos 86 campos divididos em 15 blocos macro (0 + A–N). Imutável (extensões via proposta formal).
  • Tier de artefato — Conceito descartado em MDS. Não se diz “tier 1/2/3” — diz-se “categoria de bloco” e “composição modular”.

V

  • Validator — Agent que verifica completude de uma instância MDS (BASE preenchidos, PLUGIN com resposta de gatilho). Sub-fase do process-enforcer Modulareasy.
Voltar para MDS