Contexto
O Data Boar já mantém diagramas Mermaid com fonte versionada, e o ecossistema Bestial prevê composição de capacidades via plugin/sidecar. Precisamos tornar a arquitetura legível sem presumir que toda relação já está implementada.
O escopo será feito em duas etapas deliberadas: primeiro mapear o Data Boar, que já é um sistema complexo e fornece o caso para validar o método; depois expandir para o roster completo, preservando evidências por repositório e detalhando as relações entre Bestiais.
Objetivo
Criar uma fonte de verdade legível e um fluxo reutilizável para documentar:
- A arquitetura e os fluxos internos do Data Boar.
- Em uma segunda etapa, o roster inteiro e a composição de capacidades entre produtos — incluindo sidecars/plugins que emprestam superpoderes de uma Bestial para outra.
Cada etapa deve separar comportamento implementado de arquitetura planejada, proposta ou ainda sem evidência.
Fase 1 — Data Boar como baseline
Mapear primeiro o Data Boar em profundidade, usando o repositório canônico e fontes autoritativas:
- Componentes e fronteiras internas relevantes: interfaces de entrada, pipeline de scan, coletores/conectores, plugins, processamento, evidência/auditoria e saídas.
- Fluxo dos dados e da evidência: o que entra, o que é processado, o que é persistido/emitido e em que fronteira.
- Modos de execução e fronteiras de confiança/licença quando documentados: core, capacidades opcionais, plugins/sidecars, Safe-Hold/degradação.
- Estado de cada elemento e relação: implementado/validado, planejado, proposto/investigação ou sem evidência.
- Mermaid versionado e tabela de componentes/fluxos com referências a arquivos, testes, ADRs, plans e issues.
Gate de saída: revisar o mapa do Boar e ajustar o esquema de entidades, relações, status e proveniência antes de usá-lo no roster. O mapa não precisa remodelar toda a implementação; deve explicar as fronteiras e fluxos arquiteturalmente importantes com fontes verificáveis.
Fase 2 — roster Bestial completo e relações entre repos
Só depois da validação da Fase 1, estender o método ao roster inteiro:
- Reconciliar a lista de Bestiais e produtos com a fonte canônica atual; identificar repo, missão e maturidade de cada um.
- Para cada Bestial, registrar capacidades oferecidas/consumidas, interfaces e contratos relevantes, entradas/saídas, estado e fontes autoritativas.
- Mapear relações provider → capacidade/contrato → consumer, inclusive capacidades expostas via plugin/sidecar que outra Bestial pode consumir.
- Distinguir composição via contrato de dependência direta, herança ou chamada BFF→BFF. Só desenhar a forma de integração que as fontes comprovem.
- Detalhar os eixos relevantes para cada relação, quando aplicáveis: transporte/runtime (in-process, sidecar local, remoto), identidade e trust, entitlement, limites de dados (metadata-only/real-data opt-in), falhas e Safe-Hold.
- Produzir uma visão global do roster e vistas legíveis por capacidade/fluxo, sem transformar o grafo em uma teia ilegível. Usar tabelas e diagramas separados quando necessário.
Uma capacidade de uma Bestial pode ser emprestada a outra, mas isso não implica que todo par de Bestiais seja interoperável nem que todas as capacidades estejam disponíveis em todos os deployments.
Skill/workflow reutilizável
Avaliar e, se adequado, adicionar ao repo um workflow/skill read-only para manter as duas etapas:
- Começar pelo Data Boar e usar esse caso para validar o modelo.
- Reutilizar o modelo aprovado na coleta cross-repo da Fase 2.
- Vincular cada entidade/aresta à evidência encontrada; sinalizar links ausentes, status desatualizados e relações sem fonte.
- Não inferir capacidades a partir de nomes ou proximidade semântica.
- Seguir os padrões de agente e documentação do repo. Não presumir que “Chartify” é a ferramenta ou o nome correto.
Regras de modelagem
Cada componente e relação deve distinguir explicitamente:
- Implementada/validada — evidência em código, teste ou documentação canônica.
- Planejada — aceita em issue/plan/ADR, ainda não entregue.
- Proposta/investigação — hipótese em aberto.
- Desconhecida/sem evidência — não desenhar como integração existente.
Registrar a origem verificável (repo + arquivo/issue/ADR/PR). Não inferir integração só por missão, nome, roadmap implícito ou menção sem status. Ausência de evidência deve permanecer explícita.
Aceite
Fase 1 — Data Boar
Fase 2 — roster completo
Workflow e qualidade
Fora de escopo
- Implementar novos sidecars, plugins, contratos ou integrações.
- Declarar que todas as Bestiais podem chamar todas as outras.
- Alterar o Plugin SDK ou redefinir fronteiras L1/L2/L3 nesta issue.
- Criar produto de visualização ou dependência externa obrigatória.
- Tratar o mapa como inventário de runtime ou evidência de execução atual.
Relacionadas
Prioridade sugerida: P2 · documentação/arquitetura do ecossistema.
Contexto
O Data Boar já mantém diagramas Mermaid com fonte versionada, e o ecossistema Bestial prevê composição de capacidades via plugin/sidecar. Precisamos tornar a arquitetura legível sem presumir que toda relação já está implementada.
O escopo será feito em duas etapas deliberadas: primeiro mapear o Data Boar, que já é um sistema complexo e fornece o caso para validar o método; depois expandir para o roster completo, preservando evidências por repositório e detalhando as relações entre Bestiais.
Objetivo
Criar uma fonte de verdade legível e um fluxo reutilizável para documentar:
Cada etapa deve separar comportamento implementado de arquitetura planejada, proposta ou ainda sem evidência.
Fase 1 — Data Boar como baseline
Mapear primeiro o Data Boar em profundidade, usando o repositório canônico e fontes autoritativas:
Gate de saída: revisar o mapa do Boar e ajustar o esquema de entidades, relações, status e proveniência antes de usá-lo no roster. O mapa não precisa remodelar toda a implementação; deve explicar as fronteiras e fluxos arquiteturalmente importantes com fontes verificáveis.
Fase 2 — roster Bestial completo e relações entre repos
Só depois da validação da Fase 1, estender o método ao roster inteiro:
Uma capacidade de uma Bestial pode ser emprestada a outra, mas isso não implica que todo par de Bestiais seja interoperável nem que todas as capacidades estejam disponíveis em todos os deployments.
Skill/workflow reutilizável
Avaliar e, se adequado, adicionar ao repo um workflow/skill read-only para manter as duas etapas:
Regras de modelagem
Cada componente e relação deve distinguir explicitamente:
Registrar a origem verificável (repo + arquivo/issue/ADR/PR). Não inferir integração só por missão, nome, roadmap implícito ou menção sem status. Ausência de evidência deve permanecer explícita.
Aceite
Fase 1 — Data Boar
Fase 2 — roster completo
Workflow e qualidade
Fora de escopo
Relacionadas
Prioridade sugerida: P2 · documentação/arquitetura do ecossistema.