Pular para o conteúdo principal

MDS · Modular Development Style

Glossário

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

Versão 1.1 · Atualizado em 04 de agosto de 2026

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.
  • Alcance (de um card): as três checagens que fecham um card além do critério do requisito, uso, navegação e autonomia, mais a declaração de quem alimenta a peça em produção. Card sem alcance percorrido não fecha. (Cravado 2026-08.)
  • 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.
  • Arquivo de construção do projeto: arquivo que vive no repositório do projeto e governa o ciclo de construção (por onde retomar, quando parar, fatos duráveis do ambiente). Nunca é publicado, porque carrega fatos de infraestrutura, e não é o quinto companheiro: a família publicada continua sendo cinco. (Cravado 2026-08.)

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 e A 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

  • Documento de passagem: relato do estado e do próximo passo, escrito para quem retoma o trabalho. Em projeto com família MDS publicada não se escreve: o estado vive nos artefatos publicados e a construção parte do Roadmap. Segue sendo o caminho certo onde não existe família publicada, como trabalho exploratório, prova de conceito e correção pontual. (Cravado 2026-08.)
  • 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

  • Falseabilidade (de um requisito): propriedade obrigatória de todo requisito, a frase “este requisito é violado quando ___” precisa fechar com um fato verificável. Enumeração aberta (“eventos como A, B e C”) é ilustração, não requisito. Requisito que nada reprova é o mesmo defeito de um RF sem H1. (Cravado 2026-08.)

  • 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, que são 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 e A 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: Verificação automatizada da completude de uma instância MDS (BASE preenchidos, PLUGIN com resposta de gatilho explícita).
Voltar para MDS