haos-auditoria-master

Files (1)

• SKILL.md

SKILL.md (first lines)

# HAOS Auditoria Master (playbook)

Auditar um sistema HAOS inteiro sem quebrar nada e sem inventar problema. O metodo
tem uma unica lei acima de todas: **Regra #0, verificar antes de afirmar (VBA)**.
Auditor que crava sem evidencia produz correcao errada em cima de premissa falsa,
que e pior do que nao auditar.

> Regra de bolso desta skill: **"nao achei em X" NUNCA e "nao existe".** Metade do
> que parece ponta solta e texto morto, e parte do que parece ponta solta e real
> mas nao esta onde o auditor olhou.

---

## a) Quando usar (gatilhos)

Dispare esta skill quando o pedido soar como:

- "auditoria master" / "auditoria completa do sistema"
- "vasculha tudo, acha buraco e ponta solta"
- "audita o servidor" / "audita os runtimes"
- "caca o que ta quebrado ou fora do lugar"
- "da uma varrida geral antes de eu mexer nisso"
- antes de hardening, limpeza grande, migracao de runtime ou entrega de governanca

**Nao use** para: debug de UM sintoma especifico (isso e troubleshooting pontual),
revisao de codigo de UM PR (isso e code review), inventario de rotina (isso e
heartbeat/monitor).

---

## b) Pre-requisitos

| Item | Por que |
|---|---|
| Leitura ampla (Read / Grep / Glob) | O diagnostico e 100% leitura |
| Ferramenta de sub-agentes (Agent) | O paralelismo e o que torna a auditoria viavel |
| Acesso SSH ao servidor, chave dedicada | Auditoria da camada de infra e runtimes |
| Guard em modo ENFORCE | O main ORQUESTRA, nao executa; o guard e a garantia disso |
| Mapa do ambiente carregado | Ver skill `servidor-compartilhado` (detalhes vivem em runtime privado) |

**Secrets:** a chave SSH, tokens e senhas sao referenciados SEMPRE por NOME de
variavel do arquivo master de secrets (padrao `MASTER.env`), nunca pelo valor.
Valor de segredo nao entra em resposta, log, relatorio, commit nem arquivo
temporario. Se a auditoria ENCONTRAR um segredo exposto, o achado descreve o
arquivo e a natureza do segredo, nunca o conteudo.

---

## c) Passo a passo (o metodo real)

### Passo 1. DIAGNOSTICO: N auditores READ-ONLY em paralelo

Spawnar um sub-agente auditor por frente independente, TODOS ao mesmo tempo.
Frentes que se provaram bem separadas no ambiente local:

| Frente | Escopo |
|---|---|
| (i) Nucleo | Hooks, gates/guards, arquivos de config, comandos slash, tarefas agendadas |
| (ii) Capacidades | Skills, agentes/SOULs, plugins, playbooks, duplicatas e orfaos |
| (iii) Infra | Servidor, containers, runtimes, cron, systemd, backups, firewall, disco |
| (iv) Memoria/cerebros | Indice x arquivos reais, contradicoes, drenos, espelhos, orfaos |

**Briefing obrigatorio de cada auditor:**

1. **SO LEITURA.** Proibido editar, mover, deletar, reiniciar, instalar. Se achar
   algo grave, ESCREVE no relatorio, nao conserta.
2. **Tag de fonte em todo achado:** `[verifiquei: <comando ou arquivo> -> <o que vi>]`.
   Sem tag com lastro, o achado e HIPOTESE e vai marcado como tal.
3. **Classificacao obrigatoria:**
   - **P0 (critico):** segredo exposto, perda de dado, servico caido, brecha de seguranca.
   - **P1 (importante):** funciona mas errado, fragil, duplicado, desalinhado do dono unico.
   - **P2 (cosmetico):** nomenclatura, doc desatualizado sem impacto, ruido.
4. **Cada achado tem 4 campos:** o que e, evidencia (comando + saida), impacto, fix proposto.
5. **Antes de cravar um NEGATIVO** ("nao existe", "sumiu", "nunca rodou"), checar por
   um SEGUNDO caminho e consultar a memoria. Um caminho so nao fecha negativo.
6. Formato de saida curto: tabela de achados + lista de "confirmados saudaveis"
   (o que foi checado e esta OK importa tanto quanto o que esta quebrado).

**Nesta fase NADA e corrigido.** Nem o "obvio de 1 linha".

### Passo 2. CONSOLIDACAO

O orquestrador junta os relatorios, deduplica (o mesmo problema aparece em 2-3
frentes com nomes diferentes), reclassifica quando a visao cruzada muda a
prioridade, e produz UM relatorio unico:

- Placar: quantos P0, P1, P2.
- Tabela por prioridade com evidencia e fix proposto.
- **Falsos alarmes desmentidos**, com a cadeia de evidencia que os derrubou. Esta
  secao e obrigatoria e e a que mais gera confianca no relatorio.
- Recomendacao de ondas de correcao (o que entra em qual onda e por que).

**Gate:** nada e corrigido sem OK explicito do dono do sistema. Relatorio primeiro,
mao no sistema depois.

### Passo 3. CORRECAO EM ONDAS (so apos o OK)

Executores sub-agentes em paralelo, um por area, **P0 primeiro**. Uma onda so
comeca quando a anterior fecha com evidencia.

**Regras duras da correcao:**

1. **Arquivar, NUNCA deletar.** O que sai de uso vai para `_archive/` (ou
   `_archive-<categoria>/`), FORA do diretorio que o sistema carrega, para nao
   voltar como namespace ativo.
2. **Backup antes de editar**, com sufixo datado, ex.: `arquivo.py.bak_wave1_AAAAMMDD`,
   guardado em pasta de backups do proprio componente.
3. **Segredo nunca em tela.** Mover valor para o arquivo de secrets, referenciar
   por NOME de variavel, destruir o arquivo exposto, confirmar que o consumidor
   continua funcionando. Nao ecoar o valor em nenhum momento.
4. **Regra #0 em tudo:** cada executor tambem verifica antes de afirmar que corrigiu.
5. **Uma mudanca por vez em componente stateful.** Corrigiu, validou, proxima.

**Conselho para decisao polemica.** Quando a correcao envolve trade-off de design
(o que fica no doc, quebrar compatibilidade, mudar contrato), spawnar sub-agentes
com **lentes OPOSTAS**: defensor da opcao A, defensor da opcao B, advogado do
diabo (ataca as duas). O orquestrador sintetiza e leva a decisao ja com os dois
lados escritos. Isso evita que a auditoria vire opiniao unica disfarcada de tecnica.

From simtransforma/HAOS-CC-Model, MIT.

More from simtransforma/HAOS-CC-Model