ROADMAP DE IMPLEMENTAÇÃO — MDS

O artefato durável que transforma um DRS aprovado em tarefas claras, em sequência, com checklist de feito ou não feito, orientadas a verificação-primeiro (TDD). É o companheiro de todo DRS: o DRS diz o que o sistema deve fazer; o Roadmap diz em que ordem construir e como saber que cada parte funciona.

Por que existe

Um DRS responde “o que” e “por quê”. Sozinho, ele não diz por onde começar nem como provar que cada requisito ficou pronto. O Roadmap fecha essa lacuna: pega os requisitos do DRS e os ordena em uma fila de tarefas executáveis, cada uma com seu teste, transformando a especificação em um plano de construção verificável e acompanhável.

O Roadmap é a materialização do Passo 7 do Guia de Aplicação: o handoff de implementação deixa de ser um texto efêmero de uma sessão e vira um documento publicado, vivo e compartilhado.

Princípios

1. Verificação-primeiro (TDD)

Cada tarefa declara primeiro o teste, depois a construção. O teste é o observável que prova que a tarefa está pronta:

Em projeto de código, é o teste automatizado que falha antes de existir a implementação e passa depois (TDD clássico: red, green, refactor).
Em projeto de configuração de plataforma (sem código próprio, como uma implementação de CRM), é o critério observável que se confere após configurar: “ao mover o card para X, um registro Y aparece em Z em menos de N minutos, sem digitação manual”.

A ordem nunca se inverte: escreve-se o “como verificar” antes do “como construir”. Uma tarefa sem teste declarado não entra no Roadmap.

2. Sequência e dependência

As tarefas seguem a ordem de construção definida na seção de Entrega do DRS (as ondas/módulos e seu grafo de dependências). Uma tarefa nunca aparece antes daquela de que depende. O Roadmap é lido de cima para baixo: terminou a de cima, começa a de baixo.

3. Rastreabilidade ao DRS

Cada tarefa aponta para o(s) requisito(s) funcional(is) que satisfaz. Inversamente, todo RF do DRS é coberto por ao menos uma tarefa: o Roadmap é uma cobertura completa do DRS, não um resumo. Se um RF não tem tarefa, falta tarefa; se uma tarefa não tem RF, ou falta requisito no DRS ou a tarefa é supérflua.

4. Código estável por tarefa

Cada tarefa tem um código curto e estável (ex.: F1-03, lê-se “Fase 1, tarefa 03”). O código é a âncora da tarefa (para referência cruzada) e o identificador do seu estado no checklist. Códigos não são renumerados: tarefas novas recebem códigos novos no fim da fase.

5. Estado compartilhado e durável

O feito/não feito de cada tarefa é persistido e compartilhado: quem abre o link vê o mesmo progresso. Há uma barra de progresso por documento (e, quando útil, por fase). O Roadmap é a fonte da verdade do andamento da construção, não uma planilha paralela.

6. Link mútuo com o DRS

O DRS aponta para o seu Roadmap e o Roadmap aponta de volta para o seu DRS. Os dois são publicados juntos e evoluem juntos.

Anatomia de uma tarefa

Cada tarefa é um card expansível: o cabeçalho traz o checkbox, o código e o título (fácil de ler e marcar); ao abrir, mostra os detalhes do requisito. Formato canônico: a primeira linha é o checkbox com código e título; as linhas seguintes, indentadas, são o corpo (o detalhe que vira o acordeon).

- [ ] {F1-03} Título curto da tarefa
  **RF-XXX-00N** — Nome do requisito que a tarefa cobre.
  **O que implementar:** os passos concretos de configuração/construção.
  **Como verificar (teste primeiro):** o observável que prova que a tarefa está pronta.
  **Aceite (H1):** Dado..., Quando..., Então..., E... (o critério de aceitação do RF).

O - [ ] (ou - [x]) é o checkbox; o estado real vive no banco, o markdown só declara o item.
O {F1-03} é o código estável, identificador do estado e âncora de referência.
As linhas indentadas são o corpo do card; a ordem é teste antes de construção (a regra TDD), e o corpo sempre traz o RF coberto e o critério de aceite, para que o detalhe do requisito esteja à mão sem sair da tarefa.
Tarefas que cobrem mais de um RF listam todos no campo do requisito.

As tarefas são agrupadas por fase (cada fase = uma onda/módulo da seção de Entrega do DRS), com um cabeçalho de fase e uma Definição de pronto da fase ao final. Na renderização, o card abre/fecha ao clique no título (acordeon), o checkbox marca feito/não feito, e há controles de Expandir/Recolher tudo com barra de progresso.

Estrutura recomendada do documento

Como usar este roadmap (o que é, como o checklist funciona, que o progresso é salvo e compartilhado).
Mapa de cobertura (tabela fase, módulo do DRS, RFs cobertos).
Fase 0, Planejamento (28 cards P0- já concluídos na aprovação do DRS) e demais fases, na ordem das ondas do DRS, cada uma com suas tarefas e a definição de pronto.
Encerramento (o que marca o projeto como concluído; o que fica para fases futuras condicionais).

Infraestrutura (Modulareasy)

O Roadmap é um documento doc_kind = 'roadmap' com parent_slug igual ao slug do DRS. O checklist é renderizado de forma interativa a partir das linhas de task-list do markdown (os códigos viram identificadores), e o estado de cada item é gravado em tabela própria, compartilhado entre todos que acessam o link. Em entregas white-label, o Roadmap herda a mesma identidade visual do DRS.

O Roadmap não substitui o DRS nem a seção de Validação: ele os operacionaliza. O DRS continua a fonte única da verdade conceitual; o Roadmap é a fila de construção verificável que sai dele. Seus pares são o Inventário de Artefatos, que garante que nada que precisa existir ficou de fora, as Jornadas dos Atores, que descrevem como cada papel opera o sistema, e o Plano de Testes, validação Alfa e Beta.

Roadmap de Implementação