GUIA DE APLICAÇÃO — MDS

Como instanciar o MDS em qualquer projeto novo ou existente. Roteiro operacional.

Pré-requisitos

• Conhecimento prévio do Manifesto (7 princípios + 12 anti-patterns)
• Conhecimento da Nomenclatura dos Blocos (BASE/PLUGIN/STACK)
• Leitura do Template Completo (75 campos em 15 blocos: 0 + A–N)

Roteiro de aplicação em 5 passos

Passo 1 — Decidir formato do artefato

Toda instância MDS é um documento que renderiza o template. O formato varia conforme contexto:

A categoria de cada bloco (BASE/PLUGIN/STACK) não muda com o formato — só muda a quantidade de páginas que cada bloco ocupa.

Passo 2 — Preencher os 18 BLOCO-BASE

Antes de qualquer outra coisa, preencher TODOS os 18 BASE com conteúdo real (não placeholder). Lista completa:

1. A1 Nome do sistema
2. A2 Problema que resolve
3. A3 Domínio
4. A4 Stakeholders
5. A5 Glossário
6. A6 Escopo + Não-escopo
7. A7 Premissas e restrições
8. B1 Atores
9. B3 Jornadas principais
10. C1 RFs catalogados
11. D1 Performance esperada
12. D2 Segurança/auth
13. D5 Auditabilidade (Modulareasy)
14. D10 Cadastro progressivo (Modulareasy)
15. G1 Stack
16. H1 Spec mínima por RF
17. I1 Estratégia de testes
18. I2 Critérios de aceitação
19. L1 Política de entitlement (Modulareasy)
20. M1 Mapa de automações cross-módulo (Modulareasy)

Nota: na contagem aparece 20 porque 4 são “BASE Modulareasy-opinionated” — instâncias externas podem tratar como PLUGIN. Modulareasy sempre BASE.

Se algum BASE não pode ser preenchido → STOP: você ainda não tem projeto, tem ideia. Volte 1 fase (elicitação conceitual) e responda os campos antes de prosseguir.

Passo 3 — Iterar pelos 30 BLOCO-PLUGIN respondendo gatilhos

Para cada PLUGIN do template, perguntar o gatilho em voz alta (literalmente, em formato S/N):

• “Há ≥2 perfis humanos com permissões distintas? S/N” — se S, preencher B2.
• “Há cálculo/lógica não-trivial OU regra mutável por admin? S/N” — se S, preencher C2.
• … (continuar pelos 30)

Para cada resposta N, escrever N/A — [motivo em 1 linha] no campo. Sem exceção.

Tempo realista: 30 PLUGIN × 30 segundos cada = ~15 minutos pra responder todos os gatilhos. Preenchimento de conteúdo dos que disparam varia por projeto.

Passo 4 — Avaliar os 14 BLOCO-STACK

Para cada STACK, perguntar honestamente:

• “O projeto está num nível de maturidade/criticidade que justifica este bloco?”

Se sim → preencher. Se não → omitir (sem necessidade de declarar N/A). Sem pressão de checklist completo. STACK acompanha o projeto crescer.

Passo 5 — Validar com check de coerência

Antes de declarar instância MDS pronta:

• Todos os 18-20 BASE preenchidos com conteúdo real (não placeholder)?
• Todos os 30 PLUGIN têm resposta de gatilho explícita (preenchidos OU N/A — motivo)?
• Não há contradição entre blocos (ex: D1 promete sub-200ms E I7 omitido sem performance tests planejados)?
• Princípios 5, 6, 7 do Manifesto refletidos nos blocos L e M (Modulareasy-opinionated)?
• Anti-patterns do Manifesto auditados (banner-fix, gambiarra, hardcode, falha silenciosa, etc)?

Se tudo OK → instância MDS está completa pra revisão por stakeholder humano.

Modos de aplicação

Modo Greenfield (projeto novo)

Aplicar passos 1-5 em sequência antes de escrever código.

Modo Brownfield (projeto existente sem doc MDS)

1. Aplicar passos 1-5 lendo o código + entrevistando time
2. Identificar gaps (campos BASE faltantes = débito de elicitação)
3. Documentar gaps em backlog de “completude MDS”
4. Pagar débito incrementalmente sem parar entrega

Modo Audit (validação periódica)

1. Comparar instância MDS atual vs estado real do projeto
2. Identificar drift (RFs implementados não listados, ADRs não documentados, mudanças de stack não refletidas)
3. Refresh do documento

Modo Validator (agent automatizado)

Sub-fase do process-enforcer Modulareasy:

1. Lê doc MDS de um projeto
2. Para cada BASE: verifica se preenchido (não placeholder)
3. Para cada PLUGIN: verifica se tem resposta de gatilho explícita
4. Para cada gatilho S: verifica se conteúdo está preenchido
5. Reporta gaps mecânicos

Erros comuns

”Pulei o BASE A6 (não-escopo) porque era óbvio”

Defeito. Não-escopo declarado salva 80% das discussões futuras de “achei que ia ter X”. Nunca pule.

”PLUGIN D6 (compliance) — coloquei N/A porque não sei se LGPD aplica”

Defeito. Gatilho não respondido. Resposta correta: descobre se LGPD aplica (5 minutos lendo), responde S ou N concretamente.

”STACK G6 (padrões de código) — sou solo dev, não precisa”

OK. STACK pode ser omitido sem justificativa. Mas quando entrar 2º dev, este STACK vira urgente.

”Inventei um campo que não está no template porque meu projeto é especial”

Defeito. Extensões do template precisam de proposta formal (vira evolução MDS, não fork local). Toda instância usa o template canônico.

”Coloquei tudo como BLOCO-BASE pra forçar disciplina”

Defeito. Reclassificação local quebra portabilidade. Categoria de bloco é canônica MDS, não escolha de instância.

Velocidade esperada de aplicação

Anti-pattern detectado em produtos Modulareasy: subestimar tempo de elicitação porque “o produto é claro na minha cabeça”. CANON ModularHub teve 33 seções construídas em 7 sessões. MDS é deliberado.