MANIFESTO — Modular Development Style
7 princípios que guiam o MDS. Toda decisão de design da metodologia deriva deles. Inviolável.
1. Blocos que se encaixam, não monolitos que se quebram
Todo sistema é uma composição de blocos com responsabilidades claras e interfaces explícitas. Um bloco bem desenhado encaixa em qualquer projeto que aceite seu tipo — independente do porte. Monolitos são proibidos como princípio: até a especificação de um endpoint solitário é um BLOCO-BASE, pequeno mas com encaixe definido.
2. Universal nos conceitos, escalável no artefato
A mesma metodologia descreve um script de 30 linhas e um produto SaaS de 12 módulos. O que muda não é o vocabulário, é a profundidade de cada bloco. Adicionar conceitos novos pra projeto grande gera fragmentação; subtrair conceitos pra projeto pequeno gera ritual cargo-cult. MDS classifica obrigatoriedade, nunca subtrai vocabulário.
3. Obrigatoriedade declarada, nunca presumida
Existem três categorias de bloco — BASE, PLUGIN, STACK. Cada bloco do template carrega sua categoria explícita. Quando um PLUGIN não dispara, o documento declara formalmente N/A — [motivo] em uma linha. Omissão silenciosa é defeito de processo, não economia de esforço. Quem omite paga a dívida no primeiro bug.
4. Gatilhos mecânicos, não julgamento subjetivo
Cada BLOCO-PLUGIN tem gatilho binário: “tem persistência? S/N”. Resposta sim → bloco obrigatório. Resposta não → N/A. Decisão não passa por julgamento estético (“achei que não precisava”). Subjetividade no preenchimento de templates é a raiz da inconsistência operacional.
5. Sistema trabalha pra você, não você pro sistema
(Princípio §29 do ModularHub, elevado a princípio universal MDS.)
Todo bloco do template responde a 4 perguntas: o que isso automatiza pro usuário? que evento em outro bloco isso dispara? onde cabe um botão “Gerar com IA”? que dados já existem que esse bloco pode CONSUMIR (em vez de pedir pro usuário digitar de novo)? Bloco que só captura sem retornar valor é defeito de design.
6. Cadastro progressivo, nunca bloqueante
(Princípio CANON §11 do ModularHub, elevado a princípio universal MDS.)
Em todo bloco com campos editáveis, somente o campo identificador é obrigatório. Demais campos são NULL/opcionais por padrão. O sistema USA campos quando preenchidos; AUSÊNCIA nunca bloqueia operação. Forçar preenchimento upfront é hostilidade de UX disfarçada de validação.
7. Tudo é entitlement, nada é hardcoded
(Princípio CANON §6 do ModularHub, elevado a princípio universal MDS.)
Toda decisão de comportamento, regra de negócio, limite, preço, feature flag, ON/OFF de funcionalidade tem que ser configurável em runtime via UI de admin. Hardcode que exige migration, edição de DB ou deploy pra mudar configuração é defeito de processo. Skill canônica admin-editability-first enforça em todos produtos Modulareasy.
Princípios negativos (anti-patterns proibidos)
Esses padrões NUNCA aparecem em sistema construído com MDS:
| # | Anti-pattern | Por que proibido |
|---|---|---|
| 1 | Banner explicando bug em vez de corrigir | Skill fix-not-banner — UI deve mostrar dado, não desculpa |
| 2 | Gambiarra como solução final | Skill anti-gambiarra-escalada — escalada 5 etapas obrigatória |
| 3 | Hardcode de regra que admin deveria editar | Skill admin-editability-first — viola Princípio 7 |
| 4 | Trap de contagem em pricing (per-entity meter) | Pesquisa Tier 3 S7 — vetor de ódio universal |
| 5 | Falha silenciosa de I/O assíncrono | Pesquisa Tier 3 S7 — killer de confiança universal |
| 6 | Auto-delete silencioso de dados sem warning | Intercom 9m caso ancora |
| 7 | Pular smoke visual em trabalho com UI | Skill ui-smoke-test / pdf-smoke-test — humanos têm olhos |
| 8 | Economia de etapa do processo “porque o caso é simples” | Skill economia-esforco-gera-retrabalho — sempre custa 2-5x retrabalho |
| 9 | Spec sem TDD/smoke/QA/manual conforme natureza | Validação multi-modal é BLOCO-BASE |
| 10 | Notificar usuário interno via WhatsApp/Email | CANON §33.1 — internos via Central de Notificações |
| 11 | Compartilhar banco/auth/Supabase entre projetos | Skill project-isolation — isolamento absoluto |
| 12 | Documento técnico sem gatilho de obrigatoriedade explícito | Princípio 3 do manifesto |
Voto modular
Quem adota MDS aceita que:
Toda decisão de produto, arquitetura, especificação ou implementação será documentada em blocos. Cada bloco terá categoria explícita (BASE/PLUGIN/STACK). Cada bloco terá interface clara com os adjacentes. Nenhum bloco será omitido silenciosamente. Toda omissão será declarada e justificada. Tudo o que pode ser configurado por admin será configurado por admin. Tudo o que pode ser automatizado será automatizado. Tudo o que pode ser progressivo será progressivo. O sistema trabalha pra mim, não eu pro sistema.
— Wladimir Dionísio Júnior · Modulareasy · 2026