INVENTÁRIO DE ARTEFATOS, MDS

O registro verificável de tudo que precisa ser criado e cadastrado para um sistema existir: cada funil, automação, tag, campo, formulário, integração, calendário e relatório. Onde o Roadmap responde “em que ordem construir”, o Inventário responde a outra pergunta, igualmente crítica na hora de entregar: “já criei TODOS os funis? TODAS as automações? TODAS as tags?”.

Por que existe

Um sistema, por menor que seja, é feito de muitas peças que precisam ser provisionadas: pipelines, workflows, tags, campos personalizados, formulários, integrações, papéis, dashboards. O Roadmap leva o construtor pela sequência de tarefas, mas é fácil, no meio de dezenas de passos, esquecer de criar uma tag, um campo ou uma automação. O Inventário fecha essa lacuna: lista cada peça concreta, agrupada por tipo, com checkbox próprio, para que a completude seja verificável de relance.

Roadmap e Inventário são complementares e cruzam-se: a tarefa do Roadmap cria o artefato; o artefato no Inventário aponta a tarefa que o cria. Se uma foi marcada e a outra não bate, falta algo.

O que cada artefato declara

Cada item do inventário responde, no corpo do card:

O que é / Para que serve: o nome do artefato e a função que ele cumpre.
Relacionado com: o(s) RF do DRS e a(s) tarefa(s) do Roadmap que o criam, e os artefatos vizinhos (ex.: as etapas de um funil, os valores de um grupo de tags).
Onde fica: o lugar na plataforma/codebase onde o artefato é criado e vive (ex.: “Settings > Custom Fields”, “Automation > Workflows”, uma tabela, um módulo).
Especificação (como deve ser): a ficha técnica implementável do artefato, no sub-formato do seu tipo. Para um formulário, a tabela de campos (campo, tipo, obrigatório, validação, condicional, mapeamento); para um funil, as etapas com condição de entrada e saída; para uma automação, gatilho, passos e ramificações. É o campo que diz o que se constrói no lugar indicado por “Onde fica”.
Feito ou não feito: o checkbox, com estado compartilhado, igual ao do Roadmap.

Por que a Especificação é obrigatória. Sem ela, o inventário diz que um intake form existe mas não quais campos ele tem; o construtor monta o artefato por conta própria, fora da especificação, e erra. A Especificação tem o mesmo rigor do H1 de um requisito: um artefato cuja ficha não basta para construir sem perguntar é um inventário incompleto e bloqueia, exatamente como um requisito sem critério de aceite. Fichas extensas (um formulário de 20 campos, um funil de 14 etapas) vivem num apêndice de catálogo no DRS, e o card referencia.

Princípios

Agrupado por tipo. Os artefatos vêm em seções por tipo (funis, automações, tags, campos…), com uma contagem por tipo, para que “faltou criar algum funil?” seja respondível olhando uma seção.
Completude, não sequência. O Inventário não tem ordem de execução (isso é do Roadmap); ele existe para conferir que nada ficou de fora.
Cruzado com o Roadmap e o DRS. Todo artefato aponta o RF e a tarefa; toda automação/funil/tag/campo citado no DRS aparece aqui.
Código estável por artefato. Cada um tem um código curto e estável (ex.: ART-WF-07, ART-FUN-01), âncora e identificador do estado.
Estado compartilhado. O feito/não feito é persistido e compartilhado, com barra de progresso por artefato (“27 / 49 artefatos”).

Formato canônico

Mesmo formato de card do Roadmap (cabeçalho com checkbox, código e nome; corpo indentado que vira o acordeon):

- [ ] {ART-WF-07} WF-07 Nova Venda
  **Para que serve:** no submit do formulário, aplicar Won e criar o card do Financeiro.
  **Relacionado com:** RF-FRM-002, RF-FUN-002; tarefa F1-22.
  **Onde fica:** Automation > Workflows.
  **Especificação:** gatilho (formulário enviado), condições, passos em ordem com delays, ramificações, idempotência e tratamento de falha (no sub-formato do tipo automação).

As seções por tipo usam cabeçalhos; um resumo “Tipos de artefato” no topo dá a contagem de cada tipo e onde ficam.

Catálogo de tipos de artefato

Cada artefato pertence a um tipo, e cada tipo tem um sub-formato próprio de Especificação (as colunas/estrutura que a ficha preenche). O catálogo cobre 29 tipos, agrupados por família, para abranger sistemas diferentes (CRM, apps, BI, automação, e-commerce, integração, infraestrutura, financeiro, conteúdo, configuração):

Captura e dados: formulário, campo personalizado, entidade/tabela, etiqueta, segmento.
Fluxo e processo: funil/pipeline, automação/workflow, cron/agendado, máquina de estados.
Comunicação: template de mensagem, notificação, documento/PDF.
Interface: tela/página, calendário/agenda, menu/navegação.
Análise: dashboard, métrica/indicador, conector de dados.
Integração e infraestrutura: API/webhook, variável de ambiente, serviço/container, migração de dados.
Acesso e governança: papel/permissão, auditoria/log.
Negócio: produto/plano, configuração de pagamento.
Conteúdo: página/landing, asset de mídia.
Configuração e runtime: parâmetro de configuração/regra de runtime (o que o admin liga, desliga ou ajusta sem deploy).

Cada tipo entra com seu código (ART-FORM, ART-FUN, ART-WF…) e o sub-formato de ficha que garante que o artefato seja construível sem perguntar.

Infraestrutura (Modulareasy)

O Inventário é um documento doc_kind = 'inventory' com parent_slug igual ao slug do DRS. Reaproveita a mesma renderização de cards do Roadmap e a mesma tabela de progresso (o checkbox é agnóstico de tipo). O DRS, o Roadmap, o Inventário, as Jornadas e o Plano de Testes formam a família de 5 e se cruzam: cada um aponta para os outros quatro. Em entregas white-label, o Inventário herda a identidade visual do DRS.

A família MDS responde a cinco perguntas: o DRS diz o que o sistema faz; o Roadmap diz em que ordem construir e como verificar; o Inventário diz o que precisa existir e como deve ser (com a Especificação de cada artefato) e garante que nada ficou de fora; as Jornadas dos Atores dizem como cada papel opera o sistema; e o Plano de Testes diz o que validar (Alfa interno, Beta com o cliente).

Inventário de Artefatos