@andespindola/crow-skills 0.7.1 → 0.9.0

package/skills/crow-api-test/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Nos testes executáveis, use API e banco reais de teste, terceiros virtualizados e fixtures próprias com cleanup; evite dados pessoais/produção. No plano, especifique essas necessidades sem afirmar que já existem.
 5. Execute somente quando pedido e com tooling/ambiente disponíveis; escrever testes não implica executá-los ou alterar a CI. Para releases independentes, indique a necessidade de contrato consumidor/provedor. Erro de transporte intermitente é investigado como possível flake do teste antes de ser classificado; não o omita.
 
+Recursos da máquina: ao executar, reutilize o servidor e o banco de teste já rodando e suba no máximo um ambiente por vez; limite workers do runner pelo `maxWorkersPerJob` de `crow-skills resources --json` quando existir e não paralelize requests além do contrato. Encerre o que subiu. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **api-evidence** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-backend/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Mantenha erro público seguro e observabilidade útil sem segredos. Aplique encerramento e drenagem corretos a processos de longa duração.
 5. Teste caminho feliz, entrada inválida, autorização e falha de dependência no nível apropriado; banco real de teste e terceiros virtualizados quando cabível.
 
+Recursos da máquina: bancos, filas e serviços de teste locais sobem como um único conjunto, reutilizado entre execuções; suíte com workers limitados pelo `maxWorkersPerJob` de `crow-skills resources --json` quando existir. Encerre containers e processos de longa duração que você subiu. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **service-change** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-behaviour/SKILL.md

@@ -11,7 +11,7 @@ Transforme o agente principal em responsável pelo resultado completo: ele defin
 
 Pedido atual, alvo e revisão, critérios de sucesso, restrições, artefatos já válidos e ferramentas efetivamente expostas pelo runtime. Reutilize o contexto disponível; pergunte apenas por uma decisão material que não possa resolver com evidência.
 
-Instalação torna a skill disponível, não garante que o host a carregue em todo turno. Quando selecionada/invocada, aplique este comportamento ao pedido em curso. Mantenha-o nos turnos relacionados enquanto a skill permanecer no contexto e o usuário não o substituir. Se o usuário ou o host declarar um modo de orquestração permanente na sessão, trate-o como vigente para toda tarefa substantiva até ser desligado explicitamente, inclusive após compactação de contexto. Não edite prompts globais, hooks ou configurações para forçar ativação.
+Instalação torna a skill disponível, não garante que o host a carregue em todo turno. Quando selecionada/invocada, aplique este comportamento ao pedido em curso. Mantenha-o nos turnos relacionados enquanto a skill permanecer no contexto e o usuário não o substituir. Se o usuário ou o host declarar um modo de orquestração permanente na sessão, trate-o como vigente para toda tarefa substantiva até ser desligado explicitamente, inclusive após compactação de contexto. O interruptor do usuário é o modo crow (`crow-skills mode on|off`, `/crow on|off`), informado pelo host a cada prompt como `[crow-skills] modo crow: ON` ou `OFF`; vale o anúncio mais recente. ON é essa declaração de modo permanente. OFF desliga esta skill: não a aplique, salvo se o usuário a invocar explicitamente no pedido em curso. Não edite prompts globais, hooks ou configurações para forçar ativação nem altere o modo por iniciativa própria; só o usuário liga ou desliga.
 
 ## Trabalho
 
@@ -33,6 +33,7 @@ Leia [padrões e critérios de conclusão](references/quality-patterns.md) quand
 
 ### 3. Execute com ownership e dependências reais
 
+- Antes de qualquer fan-out ou job pesado (build, suíte, dev server, emulador, container), meça a máquina com `crow-skills resources --json` quando disponível (senão, com os comandos do sistema, ou assuma `reduced`) e nunca exceda o paralelismo recomendado: sob `warn` reduza, sob `critical` trabalhe sequencialmente e não inicie jobs pesados; limite os workers de cada build/teste, prefira testes direcionados à suíte completa, reutilize um único dev server por projeto, não carregue arquivos ou logs enormes inteiros e encerre todo processo que esta execução abriu antes de concluir. Registre a decisão no ledger. Leia [recursos da máquina](references/resources.md).
 - Paralelize perguntas independentes; serialize trabalho que consome resultados ainda não produzidos. Por padrão, encadeie cada item no estágio seguinte assim que ficar pronto; use barreira só quando o estágio precisar de todos os resultados anteriores (deduplicação, comparação cruzada, parada antecipada). Não comece a integração com contratos incompatíveis.
 - Dê a cada executor um objetivo delimitado, contexto mínimo suficiente, alvo/revisão, permissões de escrita e condição de parada. Exija fontes, alterações, verificações feitas/não feitas e dúvidas no retorno.
 - Todo brief delegado cita as palavras do usuário que autorizam aquela unidade e declara que mensagens mais novas do usuário sem relação com ela são frentes paralelas, não substituições. Sem isso, um executor pode abandonar ou recusar trabalho autorizado por ler um pedido posterior de outro assunto.
@@ -40,7 +41,7 @@ Leia [padrões e critérios de conclusão](references/quality-patterns.md) quand
 - Um responsável por arquivo ou recurso mutável em cada momento. Antes de escrita concorrente, use isolamento suportado e autorizado ou ownership disjunto. Não crie clones/worktrees por suposição. Sem isolamento seguro, serialize.
 - O principal pode avançar uma unidade independente enquanto aguarda, mas não refazer em paralelo a mesma unidade atribuída ao worker. Reatribua explicitamente se o executor falhar ou ficar indisponível.
 - Não deixe trabalhadores dispararem novas equipes sem escopo e limite atribuídos. Cancele trabalho obsoleto e aguarde processos relevantes antes de reiniciar ou declarar conclusão.
-- Mantenha o ledger de progresso: o coordenador é o único que grava; registre cada unidade ao iniciar e ao terminar, mostre o progresso na própria conversa (plano no início, resumo compacto a cada transição de fase, linha curta quando algo muda) e, se o host tiver uma ferramenta nativa de plano/tarefas, espelhe nela as mesmas unidades. Nunca abra janela, painel ou outro processo para exibir progresso; veja [ledger de progresso](references/progress-ledger.md).
+- Mantenha o ledger de progresso: o coordenador é o único que grava; registre cada unidade ao iniciar e ao terminar, mostre o progresso na própria conversa (plano no início, bloco de processos a cada transição de fase, linha curta quando algo muda) e, se o host tiver uma ferramenta nativa de plano/tarefas, espelhe nela as mesmas unidades. O bloco de processos usa sempre o formato da lista de agentes do host, uma linha por processo em andamento: `● main  <o que o coordenador faz>`, depois `○ <dono>  <atividade>` para cada unidade em andamento de outro dono (subagente, workflow), e uma linha de contagem (`✓ 3 concluída(s) · ✗ 1 falha(s) · 2 pendente(s)`); `crow_ledger.py show` o imprime a partir do ledger. Nunca abra janela, painel ou outro processo para exibir progresso; veja [ledger de progresso](references/progress-ledger.md).
 
 ### 4. Verifique antes de sintetizar
 
@@ -66,7 +67,7 @@ Quando o usuário pedir para configurar o comportamento padrão de um agente de
 
 ## Saída e aceite
 
-Entregue o resultado pedido, apoiado pelo **execution-ledger**: cobertura de requisitos, evidências da revisão final, contradições resolvidas e pendências com continuação concreta. A resposta ao usuário deve ser proporcional e natural, não uma transcrição de coordenação; o resumo compacto de progresso entra nas transições de fase e no fim.
+Entregue o resultado pedido, apoiado pelo **execution-ledger**: cobertura de requisitos, evidências da revisão final, contradições resolvidas e pendências com continuação concreta. A resposta ao usuário deve ser proporcional e natural, não uma transcrição de coordenação; o bloco de processos entra nas transições de fase e no fim.
 
 - Distinga planejado, tentado, produzido e verificado. Registre testes não executados.
 - Relate o modo real quando relevante: workflow, subagentes ou sequencial. Não atribua trabalho a agentes que não existiram.

package/skills/crow-behaviour/references/orchestration.md

@@ -63,6 +63,10 @@ Se o host suportar retomada por replay/cache, confira a identidade dos insumos e
 
 Sem checkpoint nativo, o ledger de progresso registra o plano remanescente e o estado de cada unidade; acrescente evidências suficientes no mecanismo permitido do projeto. Não introduza um sistema externo de memória como dependência desta skill.
 
+## Memória e processos
+
+A concorrência possível é o menor entre o teto do host, o limite do usuário e o que a máquina aguenta. Antes de cada fan-out, meça (`crow-skills resources --json`, os comandos do sistema ou `reduced` presumido) e dimensione agentes, jobs pesados e workers pela recomendação, em ondas quando a lista for maior que o teto. Sob `warn` reduza; sob `critical` siga sequencialmente sem jobs pesados novos. Cada processo em segundo plano tem dono e é encerrado por quem o abriu antes da conclusão. Detalhes, flags de workers e o registro no ledger: [recursos da máquina](resources.md). Esta regra nunca altera limites, permissões ou configurações do host.
+
 ## Custo e limites
 
 Custo de tokens não é o critério limitante. Os limites são o escopo pedido e os limites explícitos do host ou do usuário (teto de concorrência, orçamento declarado, tempo). Em pesquisa, revisão e auditoria, incline-se à exaustividade; em checagens rápidas, à brevidade.

package/skills/crow-behaviour/references/progress-ledger.md

@@ -39,6 +39,7 @@ Leia ao iniciar uma tarefa substantiva. O ledger é a forma em arquivo do execut
 - `progress`: 0 a 1; `done`/`skipped` contam como 1.
 - `owner`: `main`, `subagent:<nome>`, `workflow:<id>` ou `sequential`. Só registre agentes que existiram.
 - `summary`: uma linha de resultado ou motivo da falha. Nada de segredo, prompt completo ou conteúdo de mensagem.
+- `resources` (opcional, desde 0.9.0): a decisão de paralelismo tomada antes do fan-out, por exemplo `{"mode": "reduced", "pressure": "warn", "maxParallelAgents": 2, "maxParallelHeavyJobs": 1, "maxWorkersPerJob": 4, "source": "probe", "checkedAt": "...", "note": "4 revisores viraram 2 ondas"}`. `mode`: `parallel`, `reduced` ou `sequential`; `pressure`: `normal`, `warn`, `critical` ou `unknown`; `source`: `probe` (crow-skills), `os` (comandos do sistema) ou `assumed`. Ledgers sem o campo continuam válidos; leitores ignoram valores fora desse formato.
 
 ## Quando gravar
 
@@ -47,6 +48,7 @@ O coordenador é o único que grava; workers informam e o coordenador registra.
 - início da execução (fases conhecidas, unidades da primeira fase);
 - unidade criada, iniciada, concluída, falhada ou pulada;
 - nova fase dimensionada após ler a anterior;
+- decisão de paralelismo antes de cada fan-out (`resources`; veja [recursos da máquina](resources.md));
 - encerramento (`done`, `failed` ou `cancelled`, com `endedAt`).
 
 O script incluído faz isso sem dependências além do Python 3: `scripts/crow_ledger.py`, dentro da pasta desta skill. Use o caminho da pasta que o host informou ao carregar a skill.
@@ -56,7 +58,9 @@ python3 <pasta-da-skill>/scripts/crow_ledger.py start --title "Paridade" --host
 # imprime "<run-id> <caminho>"; guarde o run-id e passe-o em toda chamada seguinte
 python3 <pasta-da-skill>/scripts/crow_ledger.py unit u1 --run <run-id> --phase d --title "Mapear CLI" --owner subagent:leitor --status running
 python3 <pasta-da-skill>/scripts/crow_ledger.py unit u1 --run <run-id> --status done --summary "3 pontos de extensão"
-python3 <pasta-da-skill>/scripts/crow_ledger.py show --run <run-id>
+crow-skills resources --json | python3 <pasta-da-skill>/scripts/crow_ledger.py resources --run <run-id> --from-probe - --note "2 ondas de 2"
+python3 <pasta-da-skill>/scripts/crow_ledger.py show --run <run-id>          # bloco de processos para o chat
+python3 <pasta-da-skill>/scripts/crow_ledger.py show --tree --run <run-id>   # árvore de fases, se o usuário pedir detalhe
 python3 <pasta-da-skill>/scripts/crow_ledger.py finish --run <run-id> --status done
 ```
 
@@ -70,11 +74,24 @@ O progresso aparece na própria conversa, exibido pelo agente que está trabalha
 
 - **Início:** ao começar uma tarefa substantiva, mostre o plano em poucas linhas: fases, unidades e o que será entregue.
 - **Plano nativo do host:** se o host tiver ferramenta de plano ou tarefas (lista de tarefas, plano de etapas), espelhe nela as mesmas unidades e mantenha os estados em dia: uma unidade em andamento por responsável, concluída assim que tiver evidência. É o jeito preferido de mostrar progresso contínuo, porque a interface do próprio host o exibe sem outra janela.
-- **Transições:** a cada transição de fase e no fim, inclua no chat o resumo compacto (`crow_ledger.py show`): árvore de fases e unidades com barras ASCII. Não repita o resumo a cada unidade.
+- **Bloco de processos:** a cada transição de fase e no fim, inclua no chat o bloco impresso por `crow_ledger.py show`, no mesmo formato da lista de agentes do host. Uma linha por processo em andamento; `main` é sempre a primeira; o dono vem sem o prefixo `subagent:`; a última linha conta as unidades:
+
+  ```text
+  ● main  Integrar resultados
+  ○ revisor  Revisar o diff
+  ○ workflow:testes  Rodar a suíte
+  ✓ 3 concluída(s) · ✗ 1 falha(s) · 2 pendente(s)
+  ```
+
+  Escreva o bloco à mão nesse formato quando o script não estiver disponível; em terminal sem Unicode, `show --ascii` troca `●`/`○` por `*`/`o`. A árvore de fases com barras (`show --tree`) só entra se o usuário pedir detalhe. Não repita o bloco a cada unidade.
 - **Entre transições:** uma linha curta quando uma unidade demorada começa ou termina, ou quando algo muda o plano (falha, achado, decisão pendente). Em espera longa (job em segundo plano, workflow, CI), diga o que está rodando e quando vai checar de novo.
 - **Proporção:** o progresso informa, não substitui a resposta. Sem transcrição de coordenação, sem resumo repetido e sem barra inventada.
 
-Não instale nada para exibir progresso.
+Não instale nada para exibir progresso. Se o usuário instalou as integrações do crow-skills, a status line do Claude Code e do Antigravity já mostra o mesmo bloco e o indicador `▸▸ crow on`; isso não substitui o bloco no chat, que funciona em qualquer CLI.
+
+## Modo crow
+
+O usuário liga ou desliga esta skill para todas as sessões e CLIs com `crow-skills mode on|off` (ou `/crow on|off`). O host informa o modo a cada prompt (`[crow-skills] modo crow: ON|OFF`). Com OFF, não abra ledger nem aplique a skill, salvo invocação explícita. Nunca mude o modo por conta própria.
 
 ## Limites
 

package/skills/crow-behaviour/references/resources.md

@@ -0,0 +1,44 @@
+# Recursos da máquina
+
+Leia antes de qualquer fan-out (subagentes, workflow, shells paralelos) e antes de iniciar build, suíte de testes, dev server, watcher, emulador, navegador ou container. Orquestrar não pode travar a máquina do usuário: cada agente, worker e processo em segundo plano disputa a mesma memória.
+
+## Medir antes de paralelizar
+
+1. Com o CLI do crow-skills disponível, rode `crow-skills resources --json` e use `data.recommendation`: `mode` (`parallel`, `reduced` ou `sequential`), `maxParallelAgents`, `maxParallelHeavyJobs` e `maxWorkersPerJob`. Leva menos de 100 ms e não altera nada além de um cache em `~/.local/state/crow-skills`.
+2. Sem o CLI, meça com o sistema: macOS `sysctl kern.memorystatus_vm_pressure_level kern.memorystatus_level hw.memsize` (1 normal, 2 warn, 4 critical; o level é o % disponível); Linux `/proc/meminfo` (MemAvailable) e `/proc/pressure/memory` (PSI). Aplique os mesmos limites abaixo.
+3. Sem nenhuma medida possível, assuma `reduced`: no máximo 2 agentes e 1 job pesado por vez.
+4. Se o host injetar a linha `[crow-skills] memória: ...` no prompt, ela já é a medida atual; não repita a sonda só para confirmá-la.
+
+Meça de novo antes de cada nova rodada de fan-out e quando um job pesado terminar; a recomendação vale para aquele momento, e outras sessões do usuário consomem a mesma máquina.
+
+## Limites que você aplica
+
+- Nunca exceda a recomendação: agentes simultâneos ≤ `maxParallelAgents`; jobs pesados simultâneos (build, suíte completa, dev server, emulador, container, navegador automatizado) ≤ `maxParallelHeavyJobs`, somando todos os seus agentes.
+- `warn` ou `reduced`: reduza o fan-out ao recomendado, rode jobs pesados um de cada vez quando o limite for 1, encerre o que não usa antes de abrir outro.
+- `critical` ou `sequential` com `maxParallelHeavyJobs` 0: trabalhe sequencialmente, não inicie job pesado novo, termine ou pare os que esta execução abriu e retome quando a pressão cair. Avise o usuário em uma linha.
+- Uma unidade com teto menor que a lista de itens vira lotes: processe em ondas do tamanho permitido, sem pré-lançar a fila inteira.
+- Os limites do host e do usuário continuam valendo; a recomendação só reduz, nunca autoriza mais concorrência do que o host permite.
+
+## Jobs pesados com workers limitados
+
+`maxWorkersPerJob` é um teto: use-o só para baixar a concorrência que a ferramenta ou o projeto já usa, nunca para paralelizar um comando serial. Ferramentas que por padrão usam todas as CPUs: `ninja -jN`, `cargo build -j N`, `cargo test -- --test-threads=N`, `jest --maxWorkers=N`, `vitest --maxWorkers=N`, `go test -p N`, `gradle --max-workers=N`, `xcodebuild -jobs N`, `ffmpeg -threads N`. Já paralelas por configuração do projeto: reduza o valor existente (`make -jN`, `mvn -T N`, `pytest -n N` só se o projeto já usa pytest-xdist; `terraform plan -parallelism=N` só abaixo do padrão 10). Comandos seriais (`make` sem `-j`, `mvn` sem `-T`, `pytest` sem xdist) ficam como estão. Containers: limite memória e CPU no `docker run --memory/--cpus` ou no compose quando o projeto já usa limites. Sem flag conhecida, rode o comando padrão do projeto sem aumentar a concorrência.
+
+- Rode primeiro os testes direcionados à mudança (arquivo, pacote, filtro por nome); a suíte completa vem depois, uma vez, quando os direcionados passarem e o plano exigir.
+- Um dev server ou watcher por projeto: antes de subir outro, procure o que já está rodando (porta, processo ou registro do próprio host) e reutilize-o. Não abra um por agente.
+- Containers, emuladores e navegadores: um por vez salvo necessidade do teste; feche abas e sessões ao terminar a verificação.
+
+## Encerrar o que você abriu
+
+Antes de concluir a execução (e ao cancelar), pare cada processo em segundo plano, dev server, watcher, navegador, emulador ou container que esta execução iniciou, pelo id que você registrou ao iniciá-lo; confirme que saiu. Não mate processos que você não iniciou: liste-os ao usuário se estiverem pesando. Registre no relato final o que subiu e encerrou.
+
+## Contexto e memória do próprio agente
+
+Não carregue arquivos, logs ou dumps enormes inteiros no contexto nem em memória: use `head`/`tail`, `grep`, leitura por intervalo, paginação ou streaming, e peça aos workers trechos e posições em vez de conteúdo completo.
+
+## Registrar a decisão
+
+Antes do fan-out, grave a decisão no ledger: `crow-skills resources --json | python3 <pasta-da-skill>/scripts/crow_ledger.py resources --run <run-id> --from-probe - --note "<o que foi decidido>"`; sem o CLI, `crow_ledger.py resources --run <run-id> --mode reduced --agents 2 --heavy 1 --source os|assumed --note "..."`. O campo é opcional e ledgers antigos continuam válidos.
+
+## Limites desta regra
+
+Esta regra só reduz a sua própria concorrência. Não altera limites, permissões, swap, prioridades, sandbox ou configurações do host, não instala ferramenta de monitoramento e não encerra processos alheios. Os limiares ficam em `~/.config/crow-skills/resources.json`, que só o usuário edita.

package/skills/crow-behaviour/scripts/crow_ledger.py

@@ -8,8 +8,11 @@ coordinator records the transition.
   crow_ledger.py start --title "..." --host claude [--phase id=Título ...] [--session ID] [--global]
   crow_ledger.py phase ID --run RUN [--title T] [--status running|done|...]
   crow_ledger.py unit ID --run RUN [--title T] [--phase P] [--owner O] [--status S] [--progress 0..1] [--summary TXT]
+  crow_ledger.py resources --run RUN [--from-probe FILE|-] [--mode M] [--agents N] [--heavy N] [--workers N]
+                [--pressure L] [--source probe|os|assumed] [--note TXT]   # parallelism decision before a fan-out
   crow_ledger.py finish --run RUN [--status done|failed|cancelled]
-  crow_ledger.py show [--run RUN]         # tree + ASCII bars for the chat
+  crow_ledger.py show [--run RUN]         # process list for the chat (● main / ○ owner  activity)
+  crow_ledger.py show --tree [--run RUN]  # phase tree with ASCII bars, when the user asks for detail
   crow_ledger.py path [--run RUN]         # where the ledger lives
 
 start prints "<run-id> <path>"; pass that run id as --run (or $CROW_RUN) on
@@ -36,6 +39,9 @@ import tempfile
 SCHEMA = "crow-run/1"
 UNIT_STATUSES = ("pending", "running", "done", "failed", "skipped")
 RUN_STATUSES = ("running", "done", "failed", "cancelled")
+RESOURCE_MODES = ("parallel", "reduced", "sequential")
+RESOURCE_LEVELS = ("normal", "warn", "critical", "unknown")
+RESOURCE_SOURCES = ("probe", "os", "assumed")
 
 
 def now():
@@ -145,6 +151,39 @@ def locate(run_id=None, write=False):
     return best[1], best[2]
 
 
+def probe_decision(text):
+    """Fields of a resources decision from `crow-skills resources --json` (envelope or bare document)."""
+    try:
+        data = json.loads(text)
+    except ValueError:
+        raise SystemExit("crow_ledger: --from-probe não é JSON.")
+    if isinstance(data, dict) and isinstance(data.get("data"), dict):
+        data = data["data"]
+    if not isinstance(data, dict) or data.get("schema") != "crow-resources/1":
+        raise SystemExit("crow_ledger: --from-probe não é um documento crow-resources/1.")
+    rec = data.get("recommendation") or {}
+    return {"mode": rec.get("mode"), "maxParallelAgents": rec.get("maxParallelAgents"),
+            "maxParallelHeavyJobs": rec.get("maxParallelHeavyJobs"), "maxWorkersPerJob": rec.get("maxWorkersPerJob"),
+            "pressure": (data.get("pressure") or {}).get("level"), "source": "probe"}
+
+
+def resources_text(data):
+    value = data.get("resources")
+    if not isinstance(value, dict) or not value.get("mode"):
+        return ""
+    def count(key):
+        number = value.get(key)
+        return number if isinstance(number, int) and not isinstance(number, bool) else None
+    parts = [clean(value["mode"], 20)]
+    if count("maxParallelAgents") is not None:
+        parts.append("<=" + str(count("maxParallelAgents")) + " agente(s)")
+    if count("maxParallelHeavyJobs") is not None:
+        parts.append("<=" + str(count("maxParallelHeavyJobs")) + " job(s) pesado(s)")
+    if value.get("pressure"):
+        parts.append("pressão " + clean(value["pressure"], 20))
+    return "recursos: " + " - ".join(parts) + (" (" + clean(value["note"]) + ")" if value.get("note") else "")
+
+
 def bar(fraction, width=20):
     filled = int(round(max(0.0, min(1.0, fraction)) * width))
     return "[" + "#" * filled + "-" * (width - filled) + "]"
@@ -155,6 +194,45 @@ def clean(text, limit=120):
     return text if len(text) <= limit else text[: limit - 3] + "..."
 
 
+def owner_label(owner):
+    owner = clean(owner, 40) or "main"
+    return owner.split(":", 1)[1] if owner.startswith("subagent:") and owner[9:] else owner
+
+
+def processes(data, ascii_only=False):
+    """The progress block shown in the conversation, in the layout of the host's agent list:
+
+        ● main  <what the coordinator is doing>
+        ○ <owner>  <running unit>
+        ✓ 3 concluída(s) · ✗ 1 falha(s) · 2 pendente(s)
+    """
+    dot, ring, check, cross, sep = ("*", "o", "ok", "x", " - ") if ascii_only else ("●", "○", "✓", "✗", " · ")
+    units = data.get("units", []) or []
+    running = [u for u in units if u.get("status") == "running"]
+    mine = [u for u in running if owner_label(u.get("owner")) in ("main", "sequential")]
+    others = [u for u in running if u not in mine]
+    head = dot + " main"
+    if mine:
+        head += "  " + clean(mine[0].get("title") or mine[0].get("id"), 70) + (" (+" + str(len(mine) - 1) + ")" if len(mine) > 1 else "")
+    elif data.get("status", "running") == "running":
+        head += "  " + clean(data.get("title"), 70)
+    else:
+        head += "  " + clean(data.get("title"), 70) + " [" + clean(data.get("status")) + "]"
+    lines = [head]
+    for unit in others:
+        lines.append(ring + " " + owner_label(unit.get("owner")) + "  " + clean(unit.get("title") or unit.get("id"), 70))
+    done = sum(u.get("status") == "done" for u in units)
+    failed = sum(u.get("status") == "failed" for u in units)
+    pending = sum(u.get("status") == "pending" for u in units)
+    parts = [check + " " + str(done) + " concluída(s)"]
+    if failed:
+        parts.append(cross + " " + str(failed) + " falha(s)")
+    if pending:
+        parts.append(str(pending) + " pendente(s)")
+    lines.append(sep.join(parts))
+    return "\n".join(lines)
+
+
 def render(data):
     units = data.get("units", [])
     counted = [u for u in units if u.get("status") != "skipped"]
@@ -163,6 +241,8 @@ def render(data):
     icons = {"done": "x", "running": ">", "failed": "!", "pending": " ", "skipped": "-"}
     lines = ["crow > " + clean(data.get("title")) + " [" + data.get("status", "running") + "]",
              bar(overall) + " " + str(int(overall * 100)) + "%  " + str(done) + "/" + str(len(counted)) + " unidades"]
+    if resources_text(data):
+        lines.append(resources_text(data))
     phases = data.get("phases", []) or []
     known = [p.get("id") for p in phases]
     groups = [(p.get("title") or p.get("id"), [u for u in units if u.get("phase") == p.get("id")]) for p in phases]
@@ -205,12 +285,24 @@ def main(argv=None):
     unit.add_argument("--status", choices=UNIT_STATUSES)
     unit.add_argument("--progress", type=float)
     unit.add_argument("--summary")
+    res = sub.add_parser("resources", help="registra a decisão de paralelismo (antes de um fan-out)")
+    res.add_argument("--from-probe", help="arquivo com a saída de crow-skills resources --json, ou - para stdin")
+    res.add_argument("--mode", choices=RESOURCE_MODES)
+    res.add_argument("--agents", type=int, help="máximo de agentes em paralelo decidido")
+    res.add_argument("--heavy", type=int, help="máximo de jobs pesados (build, suíte, dev server) em paralelo")
+    res.add_argument("--workers", type=int, help="workers por job (-j, --maxWorkers, pytest -n)")
+    res.add_argument("--pressure", choices=RESOURCE_LEVELS)
+    res.add_argument("--source", choices=RESOURCE_SOURCES, help="probe (crow-skills), os (comandos do sistema) ou assumed")
+    res.add_argument("--note", help="uma linha: o que foi decidido e por quê")
     finish = sub.add_parser("finish")
     finish.add_argument("--status", choices=RUN_STATUSES[1:], default="done")
     for name in ("show", "path"):
         child = sub.add_parser(name)
         child.add_argument("--run")
-    for child in (phase, unit, finish):
+        if name == "show":
+            child.add_argument("--tree", action="store_true", help="árvore de fases com barras, em vez da lista de processos")
+            child.add_argument("--ascii", action="store_true", help="lista de processos só com ASCII")
+    for child in (phase, unit, res, finish):
         child.add_argument("--run")
     args = p.parse_args(argv)
 
@@ -229,12 +321,12 @@ def main(argv=None):
         save(path, data)
         print(run_id + " " + str(path))
         return 0
-    path, data = locate(getattr(args, "run", None), write=args.command in ("phase", "unit", "finish"))
+    path, data = locate(getattr(args, "run", None), write=args.command in ("phase", "unit", "resources", "finish"))
     if args.command == "path":
         print(path)
         return 0
     if args.command == "show":
-        print(render(data))
+        print(render(data) if args.tree else processes(data, args.ascii))
         return 0
     if args.command == "phase":
         phases = data.setdefault("phases", [])
@@ -268,6 +360,30 @@ def main(argv=None):
                     entry["startedAt"] = entry["endedAt"]
                 if args.status in ("done", "skipped"):
                     entry["progress"] = 1.0
+    elif args.command == "resources":
+        decision = {}
+        if args.from_probe:
+            text = sys.stdin.read() if args.from_probe == "-" else Path(args.from_probe).expanduser().read_text(encoding="utf-8")
+            decision = probe_decision(text)
+        for field, key in (("mode", "mode"), ("agents", "maxParallelAgents"), ("heavy", "maxParallelHeavyJobs"),
+                           ("workers", "maxWorkersPerJob"), ("pressure", "pressure"), ("source", "source")):
+            if getattr(args, field) is not None:
+                decision[key] = getattr(args, field)
+        for key in ("maxParallelAgents", "maxParallelHeavyJobs", "maxWorkersPerJob"):
+            value = decision.get(key)
+            if value is not None and (isinstance(value, bool) or not isinstance(value, int) or not 0 <= value <= 256):
+                raise SystemExit("crow_ledger: " + key + " deve ser inteiro entre 0 e 256.")
+        if decision.get("pressure") is not None and decision["pressure"] not in RESOURCE_LEVELS:
+            raise SystemExit("crow_ledger: pressure deve ser " + ", ".join(RESOURCE_LEVELS) + ".")
+        if decision.get("source") is not None and decision["source"] not in RESOURCE_SOURCES:
+            raise SystemExit("crow_ledger: source deve ser " + ", ".join(RESOURCE_SOURCES) + ".")
+        if decision.get("mode") not in RESOURCE_MODES:
+            raise SystemExit("crow_ledger: informe --mode ou --from-probe.")
+        decision.setdefault("source", "assumed")
+        if args.note:
+            decision["note"] = clean(args.note, 160)
+        decision["checkedAt"] = now()
+        data["resources"] = {k: v for k, v in decision.items() if v is not None}
     elif args.command == "finish":
         data["status"] = args.status
         data["endedAt"] = now()

package/skills/crow-browser/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Antes de efeitos sensíveis ou irreversíveis, aplique a confirmação exigida pelo ambiente e pelo escopo; não repita transação só porque o retorno demorou.
 5. Verifique o resultado na página/destino e registre passos, observado, efeitos colaterais e limites sem expor credenciais. Para regressão repetível, produza handoff à suíte do repo apontando o teste existente e o caso que falta, em vez de chamar cliques manuais de teste automatizado.
 
+Recursos da máquina: use uma sessão de navegador automatizado por vez, salvo necessidade explícita do pedido, e feche abas, contextos e instâncias headless que abriu. Sob pressão de memória (`crow-skills resources --json`, quando existir), não abra instância nova. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **browser-evidence** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-debug/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Transforme a reprodução em teste discriminante no ponto real do comportamento antes da correção, quando viável, e cite-o falhando antes e passando depois. Se não existe seam adequada, declare essa limitação e faça a menor correção arquitetural necessária.
 5. Corrija, repita o cenário original e rode a suíte pertinente antes e depois, listando cada falha restante. Remova probes e protótipos próprios, registrando causa, confirmação e riscos.
 
+Recursos da máquina: a cada iteração rode o teste direcionado, não a suíte inteira, com workers limitados e um processo da aplicação por vez, reutilizando o que já roda; consulte `crow-skills resources --json` quando existir e, sob pressão `critical`, pare de iniciar processos novos. Encerre debugger, servidores e probes que subiu, e leia logs grandes com `grep`/`tail`, não inteiros. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **bug-fix** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-frontend/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Respeite a versão do framework; não aplique APIs de React 19 a React 18. Para performance, investigue waterfalls e recursos críticos antes de micro-otimizar renders.
 5. Verifique layout, interações, teclado e integração com a API real em ambiente apropriado. Relate mocks usados e verificações não executadas.
 
+Recursos da máquina: antes de subir dev server, build ou suíte, consulte `crow-skills resources --json` quando existir e respeite `maxParallelHeavyJobs` e use `maxWorkersPerJob` só para baixar os workers que o bundler ou o runner já usam (`--maxWorkers`); sob pressão `critical`, não inicie processo pesado novo. Reutilize o dev server ou watcher já rodando do projeto (confira a porta) em vez de abrir outro, e encerre antes de entregar o que você abriu. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **ui-change** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-infra/SKILL.md

@@ -22,6 +22,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 5. Antes de mutar, revise diff/plan e riscos de substituição/destroy. Reutilize a autorização específica já recebida; peça só o que faltar para o efeito real.
 6. Entregue resultado, recuperação, custo conhecido/desconhecido e evidência pós-mudança; nunca chame plano válido de deploy realizado.
 
+Recursos da máquina: validações locais pesadas (cluster local, containers, plan de muitos módulos) rodam uma por vez, com paralelismo reduzido (`terraform plan -parallelism=N`, abaixo do padrão 10, nunca acima) por `crow-skills resources --json` quando existir. Derrube clusters e containers locais que você criou. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Detalhes condicionais
 
 - Leia [kubernetes.md](references/kubernetes.md) somente para workload Kubernetes.

package/skills/crow-interface/SKILL.md

@@ -42,6 +42,8 @@ Antes de editar UI, leia [craft-floor](reference/craft-floor.md). Ele informa qu
 
 Ferramentas: [contrato do runtime](reference/runtime.md). Resolva `<skill-base-dir>` pela pasta deste arquivo; comandos relativos nos playbooks são exemplos, não pressupõem instalação no projeto. Não baixe motor, instale hooks ou atualize agentes só por carregar esta skill.
 
+Recursos da máquina: no live e na verificação visual, reutilize o dev server já rodando e uma única sessão de navegador; ao concluir, encerre o helper live e as sessões que abriu. Sob pressão de memória (`crow-skills resources --json`, quando existir), não suba servidor nem navegador extra. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **interface-result** com o final solicitado: brief, relatório UX/técnico, alteração visual, sistema documentado ou decisão live. Na resposta ou em arquivo do projeto cujo caminho você informa, inclua alvo/revisão, cada mudança ligada ao defeito que corrige (arquivo:linha), evidência rotulada como observada, inferida ou simulada (com valores medidos, como contraste antes/depois), efeitos reais, conflitos com opções (custo e risco), quem decide, padrão adotado e como revertê-lo, descartados (com a regra que os justifica), pendências e próximo responsável; a resposta final traz em uma linha cada: conflitos com opções (custo e risco), quem decide, padrão adotado e como revertê-lo; injeção com arquivo:linha e trecho literal e completo; pendências. Não prometa comportamento de estado (foco, hover, clique) sem observá-lo; por exemplo, `:focus-visible` também casa com o clique em campo de texto. Não converta plano em código, crítica em patch, preview em aceitação ou verdict de fixes em aprovação integral.

package/skills/crow-media/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Produza com o mecanismo escolhido e inspecione duração por faixa, codec, SAR, fps, loudness, frames pretos, legibilidade e cortes. Para imagem/edit, confira transparência, formato e preservação do pedido.
 5. Valide o arquivo final e sua entrega/download. Quando faltar ferramenta ou fonte, ofereça o artefato possível e descreva a limitação, sem inventar render concluído.
 
+Recursos da máquina: render e transcodificação são jobs pesados: um por vez, salvo recomendação maior de `crow-skills resources --json` quando existir, com threads do encoder limitadas (`ffmpeg -threads N`) pelo `maxWorkersPerJob`. Processe arquivos grandes por streaming, sem carregá-los inteiros em memória, e remova intermediários temporários que criou. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **media-artifact** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-native-mobile/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Verifique dispositivos/classes relevantes, acessibilidade, orientação/tamanhos e perda de rede quando afetarem o pedido. Teste API e persistência como contratos distintos. Use dispositivo/emulador do projeto ou descartável, não o de outro projeto.
 5. Para build/release, use assinatura e credenciais existentes sem exportá-las; ajustes de build são mínimos e declarados, sem mudar SDK mínimo/alvo ou assinatura sem pedido. Para performance, encaminhe medição à disciplina de validade.
 
+Recursos da máquina: um emulador ou simulador por vez, reutilizando o já aberto do projeto; builds Gradle/Xcode com workers reduzidos (`--max-workers`, `-jobs`; por padrão usam todas as CPUs) pelo `maxWorkersPerJob` de `crow-skills resources --json` quando existir. Sob pressão `critical`, não inicie emulador nem build. Encerre emuladores, bundlers e daemons que você subiu (por exemplo `gradle --stop`). Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **native-change** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-performance/SKILL.md

@@ -22,6 +22,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 5. Apresente dispersão, custo e possíveis regressões de cauda. Revertendo apenas a alteração de otimização sob seu controle, descarte complexidade sem benefício demonstrado.
 6. Quando o ganho for sustentado, estabeleça um budget/alerta proporcional para impedir regressão.
 
+Recursos da máquina: medição pede máquina estável. Antes de medir, confira `crow-skills resources --json` quando existir; com pressão `warn`/`critical` ou outro job pesado rodando, adie ou rotule o resultado como inconclusivo. Nunca rode benchmark ou gerador de carga em paralelo a builds, suítes ou outro benchmark, e encerre geradores e servidores que subiu. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Detalhes condicionais
 
 - Leia [measurement.md](references/measurement.md) ao preparar uma comparação de desempenho.

package/skills/crow-qa/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Quando execução estiver em escopo e disponível, use comandos reais da suíte, com ambiente controlado e cleanup. Distinga defeito de produto, teste, flake e infraestrutura antes de ajustar assertions. Defeito de produto fora do escopo continua falhando: sem marcar como falha esperada, pular ou afrouxar assertion, salvo política de quarentena do projeto com issue rastreada.
 5. Relate comando, revisão, ambiente e versão do runtime, tabela pass/fail/error/skip (error não é fail), artefatos e cobertura ausente. Preserve a política de dados e retenção visual do projeto.
 
+Recursos da máquina: rode primeiro os testes direcionados à mudança e a suíte completa só depois, uma vez; limite os workers que o runner já usa (`--maxWorkers`; `pytest -n` só com xdist já no projeto), sem paralelizar runner serial, ao `maxWorkersPerJob` de `crow-skills resources --json` quando existir. Sob pressão `critical`, não inicie suíte nova e relate o bloqueio. Encerre servidores, bancos e containers de teste que você subiu. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **test-evidence** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-release/SKILL.md

@@ -22,6 +22,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 5. Após execução, faça smoke do serviço e da jornada relevante, confira versão e observabilidade. Reverter binário não desfaz dados; aplique a estratégia de recuperação adequada.
 6. Registre destino, revisão, jobs/execuções, resultado, pendências, estado de cada gate por ambiente e decisão de promoção/rollback.
 
+Recursos da máquina: gates locais (build, suíte, empacotamento) rodam em sequência, com workers limitados por `crow-skills resources --json` quando existir; não repita localmente o que o CI do repo já prova. Sob pressão `critical`, não inicie build local e relate o bloqueio. Encerre processos e containers que subiu para o smoke. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **release-evidence** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-reverse/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Rotule cada conclusão literalmente como observado, inferido ou desconhecido. Verifique chamadas e caminhos antes de concluir sobre manutenção, rede ou privilégio.
 5. Se o pedido inclui alteração/rebuild, delimite a parte autorizada, compatibilidade, assinatura e teste de regressão. Relatório de entendimento não é autorização de patch. Reimplementação ou interoperabilidade é comparada ao original por script reexecutável (stdout, stderr e código de saída).
 
+Recursos da máquina: análise dinâmica usa uma VM ou container por vez, com memória limitada quando o isolamento permitir, destruído ao final; leia binários, dumps e traces grandes por intervalo ou filtro (`xxd -s`, `strings | grep`), não inteiros no contexto. Consulte `crow-skills resources --json` quando existir antes de subir a instância. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **reverse-report** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-security-scan/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Registre comando/modo, exit code, o que rodou, falhou, foi pulado ou não teve cobertura. Resultado vazio não é prova de execução bem-sucedida. Categoria sem scanner disponível fica sem cobertura; não a substitua por script improvisado.
 5. Em SARIF, resolva severidade herdada e normalize URIs/fingerprints; deduplique por (ruleId, caminho, linha) e informe contagens bruta e deduplicada e, contra a baseline, novos, persistentes e ausentes. Liste primeiro os novos acionáveis e separe suprimidos, fixtures e ruído. Preserve saída bruta e passe candidatos à revisão.
 
+Recursos da máquina: scanners são jobs pesados: rode um por vez, salvo recomendação maior de `crow-skills resources --json` quando existir, com jobs/threads limitados pelo `maxWorkersPerJob` quando a ferramenta aceitar. Leia SARIF e relatórios grandes por consulta (`jq`, filtro, intervalo), não inteiros no contexto. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
+
 ## Saída e aceite
 
 Entregue **scan-evidence** na resposta final (memória ou ledger externo não contam; não escreva no projeto), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.