audit-fleet
audit-fleet é a visão cross-repo que um manager de 6+ repos não tem
de outro jeito. O octopus setup é por-repo e o workspace: compartilha
rules, mas nada mostra quais repos estão atrás do padrão. Esta auditoria faz
isso: resolve a frota e reporta, por repo, como o config Octopus real se compara
ao alvo que o time declarou no fleet.yml — baseline + perfil de stack +
tier de adoção — mais versão do Octopus e adoção de CONTEXT.md/ADR.
É a metade detect do par da frota: o audit-fleet acha o drift, o
fleet-bootstrap fecha. O relatório é feito
pra alimentar o fleet-bootstrap --from-audit. A auditoria é signal-only e
read-only — nunca muta um repo.
Pro modelo completo da frota, veja Fluxo de setup da frota.
O drift é medido contra o alvo declarado
Como a frota é multi-stack com adoção variada, “drift” só significa algo em
relação ao que um repo deveria ser. O audit-fleet calcula o alvo de cada
repo do mesmo jeito que o fleet-bootstrap calcularia — baseline ∪ perfil ∪ tier — e compara:
- Tier de adoção — tier efetivo (
hooks/precommit/qualityWorkflow) vstierdeclarado (abaixo do alvo = drift; acima também é sinalizado). - Perfil de stack / bundles — presentes vs os bundles esperados do perfil; stack detectada vs perfil declarado.
- Versão do Octopus — instalada vs a mais recente.
- Drift de rules —
*.local.md+ rules do workspace vs o baseline. - Adoção de encode —
CONTEXT.mdpresente? quantidade de ADRs?
Ele reusa os checks single-repo do audit-config em vez de reimplementá-los —
é o análogo cross-repo.
O relatório
Uma tabela por-repo (versão · tier alvo → real · perfil bate · bundles
faltando · CONTEXT.md? · ADRs · flags de drift) mais um rollup de
drift-hotspots — as maiores lacunas primeiro, pra o manager ver os maiores
gaps de padronização antes do detalhe:
Hotspots: 2/4 behind version · 3/4 no CONTEXT.md · 1/4 below target tier→ remediate with `fleet-bootstrap --apply` (or `--from-audit` this report)Modelo de execução
v1 roda localmente contra repos com checkout (sem infra), consistente com o
fleet-bootstrap. Uma GitHub Action a nível de org varrendo remotes é um
follow-up adiado no modelo de execução da frota.
Compõe com
- fleet-bootstrap — a metade de
remediação; compartilha a lista da frota; consome este relatório via
--from-audit. - audit-config — os checks single-repo que esta auditoria reusa na frota.
- audit-grounding — depende da adoção de
CONTEXT.md/ADR que isto expõe.