[BK-349] Grafo de dependências operacionais da VPS

> Aberto em 24/08/2026. Ordem revista no mesmo dia: a fatia estreita do

> grafo (reachability + includes + cron) foi promovida para a **Fase -1 do

> BK-348**, porque medir alcançabilidade antes de migrar corta a superfície de

> 943 para ~351 arquivos e revela 14 arquivos que só o cron alcança — invisíveis

> ao espelho 8.3. Este BK segue com o resto do escopo, reaproveitando as

> tabelas nodes/edges que o BK-348 vai produzir.

Problema

Ninguém consegue responder rápido: "se eu editar este arquivo, o que quebra?".

A resposta hoje está espalhada em ~48 memórias soltas e dezenas de docs:

• "re-seal obrigatório após editar arquivo monitorado, senão o MP integrity

guard spamma a cada 30min"

• "varredura de cron inclui /etc/cron.d" — 17 automações moram lá, e

crontab -l não mostra nenhuma

• "push admin nunca para cliente"
• "sigaautobot é symlink para .com.br"
• BK-345 é duas coisas diferentes (créditos de produtor no código, Web Push

nos docs) — colisão de ID que só foi descoberta por acidente

Isso é literalmente um grafo arquivo → cron → tabela → canal → audiência que

hoje vive na cabeça do ADMIN.

Por que grafo, e por que NÃO Neo4j

Os dados de negócio não são problema de grafo: 51.064 clientes, 72.368

pedidos, 12.498 sessões, 1.267 peças, 94 tabelas. MySQL resolve com JOIN.

Neo4j custaria um serviço a mais (JVM, ~1-2 GB de RAM, backup próprio, porta,

monitoramento) numa VPS de 15 GB que já carrega vários sites, PM2 e containers.

E criaria uma segunda fonte da verdade num sistema que já precisou de um

integrity guard justamente porque drift acontece.

Decisão: grafo dentro do que já existe. Duas tabelas nodes/edges em

SQLite no lado do Cérebro (Node 22, sqlite3 já no PATH) ou MySQL 8.0.45, que

já tem WITH RECURSIVE. Custo: um scanner e duas tabelas. Só migra para banco

de grafo dedicado se a travessia ficar lenta, o que neste volume não fica.

Escopo (o que fica aqui, depois da Fase -1 do BK-348)

A Fase -1 do BK-348 entrega os nós arquivo/cron e as arestas

inclui/executa. Restam para este BK:

1. Resto do scanner, lendo do código e não de doc manual:

• ~~/etc/cron.d + crontab -l → nós cron~~ (feito na Fase -1 do BK-348)
• ~~include/require do PHP → arestas arquivo → arquivo~~ (idem)
• timers systemd → nós cron (não coberto pela Fase -1)
• queries → arestas arquivo → tabela
• [[wikilinks]] das memórias → arestas memoria → memoria
• IDs BK-NNN nos docs → nós backlog, com detecção de colisão

1. Travessia por WITH RECURSIVE: "o que depende de X", "o que X afeta".
2. Consumo pelo guard. O /root/cerebro/guard/ hoje é regex sobre string de

shell. Com o grafo ele responde por travessia: "esse arquivo tem aresta

monitorado_por → mp_integrity_guard, exige re-seal". Ataca uma classe

inteira de bug em vez de um caso.

Critério de sucesso

O grafo tem que ser gerado do código, nunca escrito à mão. Doc manual não

sobrevive nesta VPS — a quantidade de .bkp_original é a prova. Se o scanner

não rodar em cron, o grafo apodrece e vira mais uma fonte que mente com

confiança.

Ligações

• Depende de BK-348 Fase 0 (limpeza do webroot).
• Consome e reforça /root/cerebro/guard/ (ver memória project_vps_guard_hooks).

Lições já colhidas no protótipo (24/08/2026)

Valem para quem for escrever o scanner definitivo:

• include literal não existe neste código. A primeira versão do scanner

achou zero arestas nos crons porque eles usam

require dirname(__DIR__) . '/data/setup.php'. Resolver __DIR__,

__FILE__ e dirname() aninhado é obrigatório, não refinamento.

• \brequire casa dentro de requires_qr e requiredScopes. Sem

(?![a-zA-Z0-9_]) no fim, o ruído inflou "não resolvidos" de 9 para 26.

• Análise estática sozinha é piso. 289 arestas web ficam como

require $helper;. Sem um passo de runtime (auto_prepend_file +

get_included_files()), o grafo não autoriza apagar nada.

• O grafo já achou um bug: admin/data/__CLASS.SQL.php inclui

/ecompact/__emails.php, que não existe em disco.