TEMPLATE COMPLETO — Modular Development Style (MDS)
Os 15 blocos macro (0 + A-N) e 75 campos canônicos. Cada campo tem categoria (🟦 BASE / 🟨 PLUGIN / 🟩 STACK). Campos PLUGIN têm gatilho binário S/N explícito.
🟦 = BLOCO-BASE (obrigatório universal)
🟨 = BLOCO-PLUGIN (obrigatório SE gatilho dispara)
🟩 = BLOCO-STACK (incremental, projetos grandes/críticos)
0. ELICITAÇÃO E DISCOVERY (pré-spec — adicionado 2026-05-27)
Bloco que PRECEDE toda especificação. Garante que o problema, o domínio e as expectativas do stakeholder foram entendidos ANTES de descrever a solução. É o “conversar muito” formalizado.
| # | Campo | Tipo | Gatilho |
|---|
| 0.1 | Fonte do problema (quem pediu, por que agora, qual a dor) | 🟦 BASE | — |
| 0.2 | Técnicas de elicitação aplicadas (entrevista, walkthrough empírico, análise de sistema existente, planilhas, observação) | 🟦 BASE | — |
| 0.3 | Processos do mundo real mapeados (como funciona hoje SEM o sistema) | 🟨 PLUGIN | Sistema substitui processo manual ou legado? |
| 0.4 | Artefatos coletados (planilhas, prints, vídeos, docs, links, gravações) | 🟦 BASE | — |
| 0.5 | Dúvidas pendentes e bloqueadores (o que ainda não sabemos) | 🟦 BASE | — |
| 0.6 | Critério de “elicitação suficiente” (quando parar de perguntar e começar a especificar) | 🟨 PLUGIN | Projeto tem >10 stakeholders OU domínio desconhecido? |
Regra: NÃO prosseguir para Bloco A com dúvidas BLOQUEANTES pendentes (campo 0.5). Resolver primeiro.
A. IDENTIDADE E CONTEXTO
| # | Campo | Tipo | Gatilho |
|---|
| A1 | Nome do sistema | 🟦 BASE | — |
| A2 | Problema que resolve (1-3 frases) | 🟦 BASE | — |
| A3 | Domínio de operação (em qual mercado/área) | 🟦 BASE | — |
| A4 | Stakeholders / Sponsor (quem paga, quem decide) | 🟦 BASE | — |
| A5 | Glossário / Linguagem ubíqua | 🟦 BASE | — |
| A6 | Escopo + Não-escopo (lista explícita do que NÃO está incluído) | 🟦 BASE | — |
| A7 | Premissas e restrições externas (legais, técnicas, comerciais) | 🟦 BASE | — |
B. ATORES E JORNADAS
| # | Campo | Tipo | Gatilho |
|---|
| B1 | Catálogo de atores (humanos + sistemas externos) | 🟦 BASE | — |
| B2 | Sub-papéis e hierarquia de atores | 🟨 PLUGIN | Há ≥2 perfis humanos com permissões distintas? |
| B3 | Jornadas principais (mínimo 1, listar todas) | 🟦 BASE | — |
| B4 | Jornadas secundárias / edge cases | 🟩 STACK | — |
| B5 | Matriz Ator × Capability | 🟩 STACK | — |
C. REQUISITOS FUNCIONAIS
| # | Campo | Tipo | Gatilho |
|---|
| C1 | Catálogo de RFs (ID + descrição + prioridade) | 🟦 BASE | — |
| C2 | Regras de negócio explícitas (cálculos, fórmulas, políticas) | 🟨 PLUGIN | Há cálculo/lógica não-trivial OU regra mutável por admin? |
| C3 | Estados e transições (state machines) | 🟨 PLUGIN | Há entidade com >2 estados E transições não-livres? |
| C4 | Eventos de domínio (catálogo + payload) | 🟩 STACK | — |
| C5 | Cross-references entre RFs (RF X depende de RF Y) | 🟩 STACK | — |
D. REQUISITOS NÃO-FUNCIONAIS
| # | Campo | Tipo | Gatilho |
|---|
| D1 | Performance esperada (latência, throughput, budget de página) | 🟦 BASE | — |
| D2 | Segurança e autorização (modelo de auth + permissão) | 🟦 BASE | — |
| D3 | Disponibilidade / SLA | 🟨 PLUGIN | Há cliente externo pagante OU dependência crítica? |
| D4 | Escalabilidade prevista | 🟨 PLUGIN | Há previsão concreta de crescimento? |
| D5 | Auditabilidade e logs (quando + quem + o quê + onde) | 🟦 BASE Modulareasy | — (elevado a BASE — CANON §9 ModularHub: “logs de tudo + rollback”) |
| D6 | Compliance regulatório (LGPD/GDPR/HIPAA/PCI/SOC2) | 🟨 PLUGIN | Aplica regulação específica? |
| D7 | Acessibilidade (WCAG AA mínimo) | 🟨 PLUGIN | Há UI pública OU exigência contratual? |
| D8 | Internacionalização (i18n + l10n + multi-moeda) | 🟨 PLUGIN | ≥2 idiomas OU ≥2 moedas? |
| D9 | Observabilidade (metrics + traces + logs estruturados) | 🟩 STACK | — |
| D10 | Cadastro progressivo / opt-in incremental (só identificador obrigatório, resto NULL) | 🟦 BASE Modulareasy | — (Princípio 6 Manifesto — CANON §11 ModularHub) |
E. MODELO DE DOMÍNIO
| # | Campo | Tipo | Gatilho |
|---|
| E1 | Entidades principais + relações | 🟨 PLUGIN | Há persistência (DB)? |
| E2 | Diagrama ER conceitual | 🟨 PLUGIN | Há >5 entidades? |
| E3 | Bounded contexts (DDD) | 🟩 STACK | — |
| E4 | Aggregates + invariantes (DDD) | 🟩 STACK | — |
| E5 | Política de versionamento de schema (migration strategy) | 🟩 STACK | — |
F. INTERFACES
| # | Campo | Tipo | Gatilho |
|---|
| F1 | Interfaces de usuário (telas, fluxos, formulários) | 🟨 PLUGIN | Há humano olhando tela do sistema? |
| F2 | APIs externas consumidas (com versão + auth method) | 🟨 PLUGIN | Há integração com serviço externo? |
| F3 | APIs / webhooks expostos (contrato versionado) | 🟨 PLUGIN | Outros sistemas consomem este? |
| F4 | Interfaces inter-módulo (matriz N×N + catálogo) — pattern POO | 🟨 PLUGIN | Há ≥2 módulos no sistema? |
| F5 | Catálogo de eventos pub/sub (com versionamento) | 🟩 STACK | — |
| F6 | Política de versionamento + deprecation (default 30d Modulareasy) | 🟩 STACK | — |
G. ARQUITETURA E STACK
| # | Campo | Tipo | Gatilho |
|---|
| G1 | Stack tecnológica (linguagem + framework + DB + hosting + runtime) | 🟦 BASE | — |
| G2 | Decisões arquiteturais (ADRs) | 🟨 PLUGIN | Há >1 decisão não-trivial com trade-off? |
| G3 | Topologia (single/multi-tenant, sharded, regiões) | 🟨 PLUGIN | Há topologia não-padrão (não-monolito-single-tenant)? |
| G4 | Diagrama de componentes | 🟨 PLUGIN | Há >3 componentes lógicos? |
| G5 | Diagrama de deployment | 🟩 STACK | — |
| G6 | Padrões de código e convenções | 🟩 STACK | — |
| G7 | Estratégia de migração / backwards compatibility | 🟩 STACK | — |
H. SPECS POR REQUISITO
| # | Campo | Tipo | Gatilho |
|---|
| H1 | Spec mínima por RF (critérios de aceitação observáveis) | 🟦 BASE | — |
| H2 | Spec estruturada 7 blocos YAML (skill agent-spec-template) | 🟨 PLUGIN | RF é complexo OU agent autônomo vai implementar? |
| H3 | Specs cross-RF (orchestration / saga / workflow) | 🟩 STACK | — |
I. VALIDAÇÃO MULTI-MODAL
| # | Campo | Tipo | Gatilho |
|---|
| I1 | Estratégia de testes declarada (qual modo aplica onde) | 🟦 BASE | — |
| I2 | Critérios de aceitação por RF | 🟦 BASE | — |
| I3 | Testes unitários (TDD/test-after) | 🟨 PLUGIN | Há lógica pura (cálculo/transformação/parser/regra)? |
| I4 | Testes de integração | 🟨 PLUGIN | Há sistema externo OU DB real consultado? |
| I5 | Smoke visual obrigatório (ui-smoke-test skill) | 🟨 PLUGIN | Há UI? (memory feedback_smoke_visual_obrigatorio_olhos_humanos) |
| I6 | QA exploratório manual | 🟨 PLUGIN | Há fluxo crítico (dinheiro/dados sensíveis/SLA)? |
| I7 | Performance tests (load + stress) | 🟩 STACK | — |
| I8 | Security audit (pentest + dependency scan) | 🟩 STACK | — |
| I9 | Accessibility audit (WCAG) | 🟩 STACK | — |
J. ENTREGA E EVOLUÇÃO
| # | Campo | Tipo | Gatilho |
|---|
| J1 | Roadmap / Pacotes de entrega | 🟨 PLUGIN | Há sequenciamento explícito de releases? |
| J2 | Dependências entre RFs (DAG de implementação) | 🟨 PLUGIN | Há grafo não-trivial (>10 RFs com ordem)? |
| J3 | Riscos e mitigations | 🟨 PLUGIN | Projeto é não-trivial (>1 sprint)? |
| J4 | Plano de rollback | 🟩 STACK | — |
| J5 | Plano de descomissionamento de legacy | 🟩 STACK | — |
K. OPERAÇÃO
| # | Campo | Tipo | Gatilho |
|---|
| K1 | Runbook / SOPs operacionais | 🟨 PLUGIN | Sistema vai pra produção? |
| K2 | Monitoramento e alertas | 🟨 PLUGIN | Sistema vai pra produção? |
| K3 | Política de backup + DR | 🟨 PLUGIN | Há dados cuja perda é dor real? |
| K4 | Plano de incidente | 🟩 STACK | — |
| K5 | Capacity planning | 🟩 STACK | — |
L. ENTITLEMENT E CONFIGURABILIDADE (Modulareasy-opinionated)
Bloco nascido do Princípio 7 do Manifesto (“tudo é entitlement, nada é hardcoded”) e do CANON §6 ModularHub (“Super Admin liga/desliga qualquer módulo, qualquer hora, qualquer cliente”).
| # | Campo | Tipo | Gatilho |
|---|
| L1 | Política de entitlement (o que admin liga/desliga em runtime via UI) | 🟦 BASE Modulareasy | — (Princípio 7 — admin-editability-first) |
| L2 | Configuração runtime vs build-time (catálogo do que é cada) | 🟨 PLUGIN | Há ≥1 config que pode mudar sem deploy? |
| L3 | White-label / customização per-tenant (logo, cor, domínio, email, termos) | 🟨 PLUGIN | Produto é multi-tenant B2B? |
| L4 | Marketplace de extensões (modelo Salesforce ISV) | 🟩 STACK | — |
M. AUTOMAÇÃO E IA-GEN (Modulareasy-opinionated)
Bloco nascido do Princípio 5 do Manifesto (“sistema trabalha pra você”) e do CANON §29 ModularHub. Diferenciador competitivo central.
| # | Campo | Tipo | Gatilho |
|---|
| M1 | Mapa de automações cross-módulo (evento X dispara ação Y) | 🟦 BASE Modulareasy | — (Princípio 5) |
| M2 | IA-gen — pontos de injeção de “Gerar com IA” (botões first-class) | 🟨 PLUGIN | Há ≥1 tela onde IA agrega valor de geração estruturada? |
| M3 | Cross-sync entre entidades (revalidation_flags pattern) | 🟨 PLUGIN | Há ≥1 entidade que aparece em ≥2 lugares? |
| M4 | Catálogo de prompts IA (templates versionados) | 🟩 STACK | — |
N. FEEDBACK LOOP PÓS-DEPLOY (adicionado 2026-05-27)
Bloco que FECHA o ciclo MDS. Sem ele, o fluxo é linear: spec → build → deploy → silêncio. Com ele, produção retroalimenta a especificação: spec → build → deploy → observe → learn → update spec. Transforma o MDS de documento em ciclo vivo.
| # | Campo | Tipo | Gatilho |
|---|
| N1 | Métricas de uso monitoradas (quais features, quais atores, frequência, abandono) | 🟨 PLUGIN | Sistema está em produção com usuários reais? |
| N2 | Canal de feedback (como usuário reporta bug, pede feature, sugere melhoria) | 🟨 PLUGIN | Há usuários externos além do time dev? |
| N3 | Processo de retroalimentação spec (como insight de prod atualiza DRS/PRD — quem decide, como documenta, qual fluxo) | 🟨 PLUGIN | Projeto tem DRS/PRD formal? |
| N4 | Health checks automáticos (uptime, error rate, latência — thresholds que disparam revisão de spec) | 🟨 PLUGIN | Sistema tem SLA? |
| N5 | Critérios de deprecação/remoção de RF (quando matar feature não usada — métricas + decisão) | 🟩 STACK | — |
| N6 | Ciclo de revisão periódica (trimestral/semestral — cadência formal de re-visitar spec vs realidade prod) | 🟩 STACK | — |
| N7 | Post-mortem template (quando incidente grave, como documentar e retroalimentar blocos D, I, K) | 🟩 STACK | — |
Princípio 5 MDS aplicado: feature que ninguém usa = feature que não trabalha pra ninguém = defeito de produto. Bloco N força observação e correção.
Resumo numérico final
| Categoria | Total | % |
|---|
| 🟦 BLOCO-BASE (universal Modulareasy) | 22 campos | 29% |
| 🟨 BLOCO-PLUGIN (condicional com gatilho) | 35 campos | 47% |
| 🟩 BLOCO-STACK (incremental projetos grandes) | 18 campos | 24% |
| Total | 75 campos | 100% |
Sobre o Modulareasy-opinionated: os campos D5, D10, L1, M1 — marcados como BASE Modulareasy — refletem convicções cravadas Wladimir. Implementação MDS por terceiros pode tratá-los como PLUGIN sem violar a metodologia. Instância Modulareasy = sempre BASE.
Como ler uma instância
Toda instância MDS de um projeto renderiza este template com:
- 🟦 preenchimento obrigatório com conteúdo real
- 🟨 gatilho respondido S/N explicitamente + ou preenchimento ou
N/A — [motivo em 1 linha]
- 🟩 omissão livre OU preenchimento se aplicável
Exemplos de instanciação em Exemplos de Instância.
