Versão 1.3 · Atualizado em 19 de setembro de 2026

CANON, Modular Development Style (MDS)

Índice vivo único de tudo que está cravado sobre o MDS. Toda nova decisão adiciona linha aqui.

1. Identidade

2. Glossário canônico

3. Os 3 tipos de bloco, definição canônica

3.1 BLOCO-BASE 🟦

Obrigatório universal. Existe em qualquer projeto, do script de 30 linhas ao SaaS multi-tenant. Quando ausente, o projeto não é descrevível pelo template. N/A é proibido.

Exemplos: nome do sistema, problema que resolve, atores principais, glossário, RFs principais, RNF de performance e segurança, estratégia de testes declarada.

3.2 BLOCO-PLUGIN 🟨

Obrigatório condicional. Tem gatilho binário S/N documentado. Se gatilho = S → preenchimento obrigatório. Se gatilho = N → declaração N/A: [motivo em 1 linha] é obrigatória. Omissão silenciosa é defeito.

Exemplos: interfaces de usuário (gatilho: “há humano olhando tela?”), modelo de domínio (gatilho: “há persistência?”), interfaces inter-módulo (gatilho: “≥2 módulos?”), compliance regulatório (gatilho: “LGPD/HIPAA/PCI aplica?“).

3.3 BLOCO-STACK 🟩

Incremental. Aplicável quando o projeto cresce em porte, criticidade ou complexidade. Omissão é livre, sem necessidade de justificativa formal.

Exemplos: bounded contexts (DDD), event catalog (pub/sub), runbooks operacionais, capacity planning, plano de descomissionamento de legacy.

4. Cores e ícones canônicos

5. Princípios (do MANIFESTO)

Os 7 princípios em Manifesto são lei:

1. Blocos que se encaixam, não monolitos que se quebram
2. Universal nos conceitos, escalável no artefato
3. Obrigatoriedade declarada, nunca presumida
4. Gatilhos mecânicos, não julgamento subjetivo
5. Sistema trabalha pra você, não você pro sistema
6. Cadastro progressivo, nunca bloqueante
7. Tudo é entitlement, nada é hardcoded

6. Os 15 blocos macro

Detalhes em Template Completo.

6.1 A família de 5 artefatos (padrão de entrega)

Cravado a partir de um projeto real de implementação (2026-06). Um DRS MDS não é entregue sozinho: gera 4 companheiros padrão. As 5 perguntas:

Os 5 cruzam-se entre si. Todo MDS pertence a uma entidade (cliente direto Modulareasy, em /mds/<slug>, ou cliente indireto de parceiro, em /mds/<parceiro>/<slug>, white-label). Detalhe operacional nos Passos 7.1 a 7.5 do Guia de Aplicação.

6.2 O estado de um card (cravado 2026-07-15)

Três dos artefatos são checklists (Roadmap, Inventário, Plano de Testes) e um card deles pode ser marcado por dois caminhos: o texto do documento, que é a declaração do produtor, e o clique na tela, que é a marcação do leitor. A regra canônica, uma só para todos os projetos, diretos e white-label:

Cada card tem um estado só: vale o clique enquanto o produtor não mudar a marca daquele card no texto, e no instante em que a marca do texto muda aquele card volta a valer pelo texto, descartando o clique vencido. Publicar nunca escreve marcação de leitor: o publish escreve texto e só texto, e o descarte do clique vencido acontece sozinho, sem depender de ninguém lembrar de um passo. Card em que o produtor não mexeu continua com o clique do leitor intacto.

Ela atende os dois modos de uso sem exceção por projeto: quando o produtor é quem acompanha, o texto é o que muda, então o texto vence; quando o leitor é quem acompanha (o caso típico do white-label, em que o documento fica aberto e o cliente marca o que já recebeu), o clique é o que muda, então o clique vence.

Por que está no canon e não num manual de operação: enquanto a regra viveu como dica de runbook, cada projeto redescobriu o mesmo defeito quando ele mordeu, e a correção pontual vazou. Um card entregue chegou a aparecer como não-feito para quem abria a página, porque um clique antigo sobrevivia à declaração nova do produtor.

6.2.1 As camadas da obra (cravado 2026-09-14)

A construção de software tem o mesmo problema que a obra civil resolveu há um século: o dono não fala com o pedreiro. Não por hierarquia, mas porque cada descida de nível atropela a execução em andamento e desfaz a coerência do conjunto. O MDS organiza as posições assim:

O fiscal acumula dois papéis da obra, o engenheiro e o arquiteto, e é por isso que ele mede o entregue, corrige o que acha, verifica no artefato publicado e nunca aceita número vindo pronto.

A camada do meio tem três obrigações, e nenhuma é opcional:

1. Pedido do dono vira artefato durador no mesmo dia (card no Roadmap, item de fila), com o recorte que ele descreveu, nunca com o recorte que cabe na fila de hoje. Recorte menor é decisão, e decisão do dono se conta a ele. Ordem que fica só na conversa não sobrevive à troca de sessão.
2. Trabalho feito sem card vira card retroativo. Senão vira regra que ninguém verifica: o trabalho existe, o requisito existe, e não há nada que reprove quando alguém o desfizer.
3. Todo fechamento diz o que está NO AR, não só o que foi fechado. “Card fechado” e “em produção” são duas coisas, e a distância entre elas se mede, nunca se presume.

O modo de falha da camada é o silêncio, e ele é pior do que a ausência dela. Quando um pedido se perde no meio de campo, o dono para de cobrar, porque acha que entregou o recado. O que se perde não é o trabalho: é a garantia de que falar com a camada equivale a falar com a obra. Por isso a Inspeção mede a si mesma com a mesma régua que usa na Execução, cruzando periodicamente o que está escrito, o que foi entregue e o que o dono pediu.

6.2.2 A prova no merge, a vitrine em lote (cravado 2026-09-19)

Na construção, cada card fechado deixava três rastros ao mesmo tempo: a prova de que passou (o plano, o teste e a revisão), a marca no checklist do documento publicado, e a lição aprendida. Feitos todos a cada card, eles consumiam perto da metade do esforço da construção, medido num projeto real: o documento publicado era reescrito card a card, a prova crescia em prosa rodada após rodada e o arquivo que governa a construção era relido inteiro a cada volta. A regra separa o que não pode esperar do que pode:

A prova e a marca entram junto com o código, no mesmo registro do card, e nunca esperam. O repositório do projeto é o estado. O documento publicado é a vitrine, e recebe as marcas em lote: a cada cinco cards, no fim de cada fase, antes de a construção pausar e, sempre, antes de começar card novo se houver algo por publicar. O topo do Roadmap declara até onde a vitrine está atualizada, para que atraso apareça como atraso e nunca como card esquecido.

Duas proteções acompanham o lote. Se alguém desmarcou na tela um card que o texto marca, aquele card fica fora do lote e volta para a fila como reabertura, porque publicar por cima apagaria a reprovação de quem acompanha. E se o documento publicado foi mudado por fora do repositório, o lote para antes de escrever, porque sobrescrever apagaria uma edição que não está guardada em lugar nenhum.

A prova também tem tamanho: um formato fixo e curto por card (veredito, cada critério numa linha com o link da evidência, e o que a mudança tira de quem já usava), rodada nova acrescenta sem reescrever, e as capturas de tela decisivas ficam junto do código enquanto o resto fica guardado fora dele. O escopo não muda: nenhum card, teste ou artefato deixa de ser marcado nem de ser provado. Muda quando a marca aparece na vitrine e quanto texto a prova ocupa. Detalhe no Guia de Aplicação, Passo 7.

6.3 Os dois papéis da construção (cravado 2026-09-01)

Quando a construção é contínua, ela ocupa duas posições ao mesmo tempo, e o MDS as separa por nome:

Sessão de Execução percorre a fila do Roadmap card a card, escreve, testa e publica. É a única que toca no que vai ao ar. Sessão de Inspeção mede o entregue contra o critério de aceite, executa a bateria Beta do Plano de Testes, encontra falhas e ordena a fila. A Inspeção não constrói.

A amputação é o que faz a coisa funcionar, e ela tem uma razão de método, não de disciplina: sendo a Inspeção o canal por onde o responsável fala enquanto a obra anda, é por ali que o escopo tentaria entrar por atalho. Sem poder construir, ela é obrigada ao caminho longo, que é o do princípio 1: pedido novo vira requisito com critério de aceite, o DRS é republicado, e só então nasce o card. É assim que “nada se constrói fora do documento” sobrevive à obra em andamento, que é justamente quando o princípio costuma ser furado.

A interface entre as duas é artefato publicado, nunca conversa. O Roadmap publicado é o estado; despachar trabalho por mensagem cria um segundo estado competindo com o primeiro, e o segundo não fica no documento que o cliente lê. Mensagem direta serve para coordenação, não para despacho.

Quem fecha o quê: a Execução fecha card de construção e nunca marca item de teste; a Inspeção fecha item da bateria Beta e nunca marca card de construção. Duas mãos no mesmo checklist é como o estado passa a mentir.

Quando vale a pena, e são três condições juntas: cinco ou mais cards abertos na fila, construção de fato em andamento, e o responsável com assunto a tratar agora. Fora disso é uma posição só, porque a segunda custa sem produzir entrega. A Inspeção é efêmera: abre, entrega, encerra.

O modo de falha é congestionamento, não estrago. A Inspeção enfileira mais rápido do que a Execução drena, e o sintoma aparece meses depois como “por que a obra ficou lenta”. Mede-se por cards fechados por semana antes e depois, e por itens injetados contra cards do Roadmap.

O escopo desta separação é a construção do projeto. Ferramenta, metodologia e infraestrutura em volta seguem sendo trabalho comum. Detalhe operacional no Guia de Aplicação, Passo 8.

6.4 A Fase M, o mockup antes da construção (cravado 2026-09)

Entre o Planejamento e a primeira fase de construção existe uma fase própria e obrigatória, a Fase M: o Mockup Navegável do sistema completo, com gate de aprovação do dono do projeto.

Nenhuma fase de construção começa com a Fase M aberta. O mockup cobre o sistema inteiro, e não a tela principal: todas as telas do catálogo do DRS, em cada variação de identidade e para cada papel, com a identidade visual oficial. Aprovado, o endereço entra no DRS como referência visual aprovada e guia do desenvolvimento.

A razão é de custo: ajuste no mockup é barato e ajuste no código é caro. Enquanto a etapa viveu como boa prática opcional, cada projeto redescobriu o mesmo retrabalho na primeira tela entregue fora do que o dono do projeto imaginava.

Quem produz o mockup é decisão do dono do projeto, tomada projeto a projeto, e os dois caminhos são legítimos: ele monta numa ferramenta de design a partir do prompt de especificação que a equipe entrega, ou a equipe monta em páginas publicadas num endereço real. O que muda é quem executa; a etapa e o gate não mudam, e decidir o caminho sozinho é furar o processo tanto quanto pular a etapa. Detalhe operacional no Guia de Aplicação, Passo 7.6, e no Roadmap de Implementação.

7. Anti-patterns

14 anti-patterns proibidos em projeto MDS. Lista canônica no Manifesto. Nos produtos Modulareasy a checagem é automática, feita pelo próprio ferramental de construção.

8. Posicionamento competitivo

9. Relação com APEX CORE

MDS e APEX CORE são metodologias proprietárias independentes da Modulareasy, com escopos complementares:

Não há sobreposição. APEX gerencia humanos que constroem software. MDS define como o software é especificado e construído.

10. Roadmap de evolução

Cravamento inicial (2026-05-26)

• ✅ Manifesto 7 princípios
• ✅ 3 tipos de bloco (BASE/PLUGIN/STACK) + nomenclatura canônica
• ✅ Template 15 blocos macro / 86 campos (incluindo Bloco 0 Elicitação e Bloco N Feedback Loop adicionados em 2026-05-27)
• ✅ Mini-projeto com pasta canônica
• ⏸️ Site público da metodologia no ar (publicado em 2026-07)

Cravamento 2026-05-31

• ✅ Gate de validação final (2 perguntas): etapa final de toda instância, suficiência (cumpre o propósito?) e conformidade (segue o MDS?). A 2ª pergunta torna cada documento um teste vivo da metodologia.
• ✅ Declaração de Conformidade MDS: registro da cobertura de blocos e das respostas de gatilho dos PLUGIN, mantido NAS NOTAS de quem produz, FORA do documento do cliente (é sobre o método, não sobre o sistema). (Corrigido no cravamento 2026-06: não vai como apêndice no DRS do cliente.)

Cravamento 2026-06

• ✅ Família de 5 artefatos como padrão de entrega: todo DRS gera Roadmap de Implementação (com a Fase 0 de Planejamento) + Inventário de Artefatos + Jornadas dos Atores + Plano de Testes (Alfa e Beta). Progresso em 3 seções 40/40/20. Passos 7.1 a 7.4 no Guia.
• ✅ Roadmap orientado a verificação-primeiro (TDD): cada RF vira tarefa verificável, em sequência, em card expansível (RF + o que implementar + como verificar + aceite H1).
• ✅ Modelo de entidade (direto vs parceiro): MDS de cliente direto (Modulareasy) em /mds/<slug>; de cliente indireto de parceiro em /mds/<parceiro>/<slug>, white-label com IDV salva do parceiro. Perguntar a entidade ao iniciar.
• ✅ Cross-referência dos blocos do DRS para os companheiros (B→Jornadas, J→Roadmap, E→Inventário, Qualidade e Testes→Plano de Testes).
• ✅ Gate e Conformidade MDS rodam FORA do documento do cliente (são sobre o método, não sobre o sistema): rodar e registrar nas notas/memória, nunca como apêndice no DRS do cliente.

Cravamento 2026-08

• ✅ A construção parte do Roadmap publicado, card a card, até os cards de construção fecharem. O estado vive no artefato publicado, não numa mensagem transmitida entre sessões. O documento de passagem segue valendo onde não existe família MDS publicada (exploração, prova de conceito, correção pontual). Passo 7 do Guia, reescrito.
• ✅ O arquivo de construção do projeto nunca é publicado. Ele vive no repositório do projeto, carrega fatos de infraestrutura e não é o quinto companheiro. A família publicada continua sendo cinco.
• ✅ Falseabilidade é propriedade obrigatória do requisito: “este requisito é violado quando ___” precisa fechar com um fato verificável, e enumeração aberta (“eventos como A, B e C”) é ilustração, não requisito. Vira checagem própria dentro da Pergunta 1 do gate, porque requisito que nada reprova passa nas duas perguntas sem esforço.
• ✅ Pronto é benefício recebido, não código verde: o card só fecha com uso, navegação e autonomia percorridos, e nomeia quem alimenta a peça em produção. As três checagens saem da fase de Testes (que roda por último por construção) e passam a valer também no fechamento de cada card. Os pesos 40/40/20 não mudam.
• ✅ Cobertura por construção vence cobertura por disciplina: trava que confere lista curada protege só o que alguém lembrou de listar; toda trava deriva o que checa do próprio material e nasce com uma prova de que reprova quando deve.
• ✅ Data e versão em todas as páginas do cânone, para que o desatualizado apareça em vez de ser tropeçado.

Cravamento 2026-09

• ✅ Fase M, o Mockup Navegável, é etapa obrigatória entre o Planejamento e a construção: mockup do sistema completo, com gate de aprovação do dono do projeto, cards M-NN no Roadmap logo depois da Fase 0. Quem produz é decisão do dono, projeto a projeto (ferramenta de design a partir do prompt de especificação entregue pela equipe, ou páginas publicadas montadas pela equipe); a etapa e o gate não mudam. Aprovado, o endereço entra no DRS como referência visual aprovada e guia do desenvolvimento. Passo 7.6 do Guia.

• ✅ A prova no merge, a vitrine em lote: a prova e a marca de cada card entram no mesmo registro do código; o documento publicado recebe as marcas em lote (cinco cards, fim de fase, pausa, e antes de card novo se houver pendência), com a data de atualização declarada no topo. Desmarcação na tela vira reabertura, e edição fora do repositório trava o lote. Prova em formato curto e fixo. Seção 6.2.2.

Próximas evoluções

• Tradução EN do site (mercado internacional).
• Aplicação retroativa nos produtos internos vivos, auditoria de completude.
• Verificação automatizada de completude de instância (lê o documento, lista campos faltantes e N/A não declarados).