Versão 1.1 · Atualizado em 04 de agosto 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.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.

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.

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).