@zaip-ai/cli 1.0.8 → 1.3.1

package/templates/.agents/dashboard/apps/frontend/dist/assets/DashboardHelpDialog-Cs6dzDmW.js

@@ -1,1505 +0,0 @@
-import{S as e,b as t}from"./cost-monitor-Cf9ctPVt.js";import{t as n}from"./dashboard-localization-CLJ0lT9v.js";var r=`# Primeiros passos
-
-1. Leia \`.agents/config/project.yaml\` e \`.agents/rules/core.md\`.
-2. Consulte \`.agents/records/lifecycle/\` para descobrir o estado atual pelos manifests canônicos.
-3. Classifique a entrada: Conversation, Task avulsa, SPEC ou PRD. Pergunta/análise read-only é Conversation e não cria Task.
-4. Carregue somente Rules, Requirements e skills aplicaveis.
-5. Defina aceite verificavel antes de editar.
-6. Antes de escrita persistente, inicie Task, Change, Execution e Run raiz do orquestrador; execute Sub-Runs, teste e registre evidencias no ciclo de vida ativo.
-
-Evite varrer \`.agents/records/\`: abra um record apenas quando possuir seu ID.
-
-Para PRD/SPEC, diferencie conversa de criação: “me ajude a pensar” não cria artefato; “crie” persiste o pacote \`draft\` completo e sua telemetria. Faça até cinco perguntas críticas por turno, no máximo três turnos; depois registre decisões delegáveis da IA. Tasks reais só nascem em \`ready|execute\`.
-`,i=`# Requirements
-
-Use Requirement para uma obrigacao duravel e testavel.
-
-1. Descreva resultado e limite, nao a implementacao preferida.
-2. Crie criterios de aceite observaveis.
-3. Registre riscos, dependencias e casos negativos.
-4. Relacione cada criterio a teste ou evidencia.
-5. Versione mudancas sem apagar a intencao anterior.
-6. Promova somente depois de validar consistencia e rastreabilidade.
-
-Um bom criterio responde inequivocamente: passou ou falhou?
-`,a=`# Tasks
-
-Use Task para uma entrega pequena, independente e com um resultado claro.
-
-1. Pedido avulso explícito de ação entra diretamente em Execução; somente preparação sem autorização de executar pode parar em Pronto para Executar.
-2. Declare objetivo, escopo e fora de escopo.
-3. Vincule Requirements aplicaveis.
-4. Liste arquivos ou componentes provaveis, sem congelar a solucao.
-5. Defina verificacoes proporcionais ao risco.
-6. Use uma Run raiz do orquestrador por tentativa, finalize os Sub-Runs de trabalho e execute o finalizador como ultimo filho.
-7. Antes de a Run terminar, mova a Task para completed, blocked, failed ou cancelled; nunca deixe executing/verifying.
-8. Retome blocked com \`task resume\`; trate failed com \`task rework\` na mesma Task. Completed/cancelled sao imutaveis.
-
-Em PRD/SPEC \`draft\`, a lista visível vem dos blueprints do PreparedPlan e não representa Tasks materializadas. \`ready\` cria os registros \`planned\`. Execução pode ser pedida diretamente no menor grão Task, sem ampliar para toda a SPEC ou PRD.
-
-## Modelo, effort e velocidade
-
-Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex. A única forma suportada de executar trabalho de produto mais rápido é usar Fast manualmente em uma Task-first realmente independente; o ZAIP não ativa nem persiste essa seleção. Uma Task descendente de PRD ou SPEC segue a orquestração automática do pai e executa sempre com velocidade \`standard\`, mesmo quando for acionada no menor grão.
-`,o=`# SPECs
-
-Use SPEC quando a entrega exige varias Tasks ou uma ordem de dependencia.
-
-1. Transforme o resultado desejado em capacidades verificaveis. Faça até cinco perguntas críticas por turno e encerre esclarecimento em até três turnos.
-2. Consulte \`stack\` e \`stack.overrides\` em \`.agents/config/project.yaml\`; este arquivo contem a definicao tecnica canonica da stack do projeto.
-3. Registre \`stack_profile\`, \`stack_overrides\`, \`stack_description\` curta e componentes com linguagem, runtime, frameworks, versoes exatas e fontes verificaveis no workspace.
-4. Registre o blueprint técnico da SPEC e divida em blueprints de Tasks pequenas, cada uma com aceite próprio; \`spec create --plan\` persiste esse pacote em \`draft\` e registros Task só são criados em \`ready|execute\`.
-5. Modele dependencias como DAG; evite sequencias artificiais.
-6. Identifique caminhos criticos, riscos e rollback.
-7. Mapeie cada Requirement para Tasks e evidencias.
-8. Valide a SPEC antes de iniciar execucao; bloqueie stack ausente, divergente ou sem versoes exatas e fontes existentes.
-9. Ao iniciar a primeira Task, mantenha a SPEC em Execucao entre todas as Runs filhas; resultado terminal de uma Task nao terminaliza a SPEC.
-10. Depois de todas as Tasks concluidas, rode verificacao e Evidence parentais antes de deliver.
-
-Uma SPEC planeja a entrega; nao autoriza mudancas externas por si so.
-
-Use uma SPEC por padrão. Separe outra somente quando as capacidades puderem ser implementadas e verificadas em paralelo contra contratos estáveis, sem dependência ou write scope conflitante. Dependências e ordem ficam na DAG de Tasks da mesma SPEC.
-
-Toda Execution originada por SPEC usa velocidade \`standard\` em suas Tasks, Runs e Sub-Runs. A seleção manual de Fast no Codex não substitui essa política. Se uma necessidade urgente for realmente pequena e independente da DAG e dos gates parentais, ela pode ser tratada como Task-first com velocidade manual; não fragmente uma SPEC artificialmente apenas para executar mais rápido.
-`,s=`# PRDs
-
-Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
-
-1. Registre problema, publico, resultado e metricas.
-2. Delimite escopo, restricoes e nao objetivos.
-3. Mantenha o PRD agnostico de linguagem, framework, banco, infraestrutura e fornecedor; tecnologia imposta externamente entra como restricao de negocio, nao como desenho da solucao.
-4. Especifique requisitos funcionais e nao funcionais.
-5. Use uma SPEC por padrão. Crie outra somente para capacidade implementável e verificável em paralelo, sem dependência entre SPECs; dependências ficam nas Tasks internas.
-6. Relacione riscos, rollout, observabilidade e rollback.
-7. Monte a DAG e confirme que todo aceite possui evidencia planejada.
-8. Mantenha PRD e SPECs selecionadas em Execucao enquanto restar trabalho; Runs filhas fecham Tasks, nao o macro.
-9. Conclua somente depois das Tasks, integracao, outcomes e gates parentais.
-
-## Intenções
-
-- “Me ajude a pensar sobre um PRD”: Conversation, sem artefato.
-- “Crie um PRD”: até cinco perguntas críticas por turno e no máximo três turnos; depois persiste PRD, SPECs e PreparedPlan \`draft\`, vincula a Run e o \`creation_run_id\` ao macro e não cria Tasks reais. Duração, tokens e custo só são agregados quando observados ou reconciliados.
-- “Deixe pronto para executar” ou “finalize/conclua esse PRD” em \`draft\`: lapida, valida e materializa SPECs/Tasks/Changes/Execution como \`ready|planned\`, sem executar.
-- “Execute esse PRD”: executa todas as SPECs selecionadas. Pedido dirigido a SPEC ou Task usa o menor grão.
-- “Implemente”: sem alvo abre apenas uma Conversation de planejamento; em \`draft\` finaliza o plano; em \`ready\` executa; em \`active|blocked|failed\` continua, retoma ou cria rework.
-- “Desenvolva/melhore/aprimore”: sempre planeja/refina/rework e nunca executa automaticamente.
-
-PRD cancelado permanece imutável. Novo planejamento cria sucessor \`draft\`, tag \`rework\` e \`rework_of_prd_id\`.
-
-## Quantas SPECs criar
-
-| SPECs | Quando usar | Exemplo |
-| --- | --- | --- |
-| 1 | Padrão; há sequência, contrato em evolução ou dependência entre frentes. | Recuperação de senha completa em uma DAG. |
-| 2 | Duas capacidades paralelas contra contrato estável e escopos separados. | Web e Mobile contra API congelada. |
-| 3 | Três capacidades entregáveis isoladamente; integração fica no PRD. | Identidade, cobrança e notificações. |
-| 4 | Quatro adaptadores independentes, com ownership e diretórios distintos. | Adaptadores fiscais de quatro países. |
-| 5 | Exceção: cinco implementações simétricas do mesmo contrato validado. | Email, SMS, WhatsApp, Push e Inbox. |
-
-Qualquer dependência técnica entre duas frentes obriga reuni-las na mesma SPEC e expressar a ordem entre Tasks. Mais de cinco exige recortar o PRD ou registrar uma decisão de exceção.
-
-Toda Execution originada por PRD usa velocidade \`standard\` em todas as SPECs, Tasks, Runs e Sub-Runs descendentes. Não existe skill, hook ou override de Fast para esse fluxo. A única execução de produto mais rápida suportada é Task-first realmente independente, com Fast selecionado manualmente no Codex; uma urgência não autoriza remover a estrutura necessária de PRD/SPEC.
-`,c=`# Execucao
-
-1. Confirme Task, Change, Execution, aceite e Run raiz do orquestrador.
-2. Antes da primeira mutacao persistente, confirme Task executing e Run raiz ativa no turno atual.
-3. Inspecione o diff e preserve alteracoes alheias.
-4. Use Sub-Runs para cada subagente; a Run raiz aguarda todos os descendentes ativos.
-5. Implemente o menor incremento coerente e rode verificacoes focadas.
-6. Registre decisoes consequenciais, evidencias e desvios.
-7. Depois dos demais descendentes, execute \`zaip-agent-finalizer\` como ultimo Sub-Run da Execution. Nenhum filho novo pode iniciar depois dele.
-8. Finalize a Run raiz com status tecnico e resultado terminal da Task separados.
-9. Execute os gates finais e documente rollback.
-
-Nao marque conclusao por esforco: conclua pelo resultado verificavel. Gate insuficiente ou finalizador ausente usa blocked; erro tecnico impeditivo usa failed; cancelamento exige pedido explicito.
-
-\`execute\` respeita o menor grão nomeado: Task executa um nó elegível; SPEC executa sua DAG; PRD executa todas as SPECs selecionadas. “Conclua a execução” ou “finalize a implementação” em trabalho ativo continua Tasks e gates, mas nunca força sucesso. “Desenvolva/melhore/aprimore” volta a planejamento/rework e exige nova promoção.
-
-## Modelo, effort e velocidade por origem
-
-- Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex.
-- Fast para execução de produto é suportado somente em Task-first realmente independente e deve ser selecionado manualmente no Codex.
-- Executions originadas por SPEC ou PRD usam sempre velocidade \`standard\`, inclusive em todas as Tasks, Runs e Sub-Runs descendentes.
-- O ZAIP não ativa, persiste ou herda Fast por skill, hook, PreparedPlan ou override de Execution.
-- Selecionar uma Task descendente como menor grão não a transforma em Task-first nem remove a velocidade \`standard\` herdada do macro.
-`,l=`# Revisao e validacao
-
-1. Revise Requirements e criterios de aceite.
-2. Examine diff, limites arquiteturais e caminhos de erro.
-3. Rode testes focados e depois gates completos aplicaveis.
-4. Verifique seguranca, compatibilidade, documentacao e rollback.
-5. Classifique achados por impacto e cite evidencia concreta.
-6. Registre o resultado sem alterar implementacao em uma revisao read-only.
-`,u=`# Contexto e tokens
-
-1. Comece por \`project.yaml\`, \`core.md\` e pelos manifests de \`.agents/records/lifecycle/\`.
-2. Carregue somente a Rule, Requirement ou skill acionada.
-3. Prefira indices, resumos e busca direcionada a arquivos completos.
-4. Abra records apenas por lifecycle ID conhecido.
-5. Resuma fatos estaveis; preserve texto literal apenas quando normativo.
-6. Remova do contexto resultados superados e detalhes nao acionaveis.
-
-Para tools, leia \`catalog.yaml\`, escolha um ID e abra somente seu manifesto.
-`,d=`# Agentes e squads
-
-1. Delegue apenas subtarefas concretas e independentes.
-2. Dê a cada agente objetivo, limites, entradas e formato de saida.
-3. Evite dois agentes editando os mesmos arquivos.
-4. Centralize decisoes arquiteturais e integracao no agente responsavel.
-5. Exija evidencias, nao apenas declaracoes de conclusao.
-6. Use paralelismo somente quando reduzir caminho critico sem aumentar conflito.
-`,f=`# Segurança dos perfis Codex ZAIP-AIOS
-
-## Visão geral
-
-O ZAIP-AIOS oferece dois perfis atuais:
-
-| Perfil | Filesystem nativo | Rede de comandos | Uso recomendado |
-| --- | --- | --- | --- |
-| \`zaip-aios-full-access\` | Escrita em \`C:\\\` inteiro no Windows, quando as permissões do sistema permitirem | Completa, todos os domínios | Default humano; a autorização de cada operação continua necessária |
-| \`zaip-aios-security\` | Escrita na raiz física do repositório, incluindo \`.git\`, \`.agents\`, \`.codex\` e demais arquivos ocultos | Limitada a \`github.com\` | Opt-in de menor privilégio; reinicie o Codex após selecionar |
-
-A permissão nativa determina o que o processo tecnicamente consegue alcançar. Ela não
-substitui autorização do usuário, regras do repositório, hooks, skills ou controles do
-sistema operacional.
-
-## \`zaip-aios-security\`
-
-### Acesso concedido
-
-O perfil restrito concede:
-
-- leitura dos caminhos mínimos necessários para executar ferramentas;
-- escrita em \`~/.ssh\` para reparar a configuração e a identidade SSH local;
-- escrita na raiz física absoluta deste repositório;
-- escrita em todos os descendentes do workspace, incluindo \`.git\`, \`.agents\`, \`.codex\` e demais arquivos ocultos;
-- rede de comandos limitada a \`github.com\` para operações Git/SSH autorizadas.
-
-Exemplo da definição efetiva:
-
-\`\`\`toml
-default_permissions = "zaip-aios-security"
-
-[permissions.zaip-aios-security]
-description = "ZAIP workspace-only development with editable project control trees and GitHub-only command network access."
-
-[permissions.zaip-aios-security.filesystem]
-":minimal" = "read"
-"~/.ssh" = "write"
-
-[permissions.zaip-aios-security.filesystem."C:\\\\caminho\\\\absoluto\\\\do\\\\workspace"]
-"." = "write"
-".git" = "write"
-".agents" = "write"
-".codex" = "write"
-
-[permissions.zaip-aios-security.network]
-enabled = true
-mode = "limited"
-
-[permissions.zaip-aios-security.network.domains]
-"github.com" = "allow"
-\`\`\`
-
-A tabela usa a raiz física em vez de \`extends = ":workspace"\` ou \`:workspace_roots\`.
-No sandbox elevado do Windows, esses dois modos aplicam negações especiais a \`.agents\` e
-\`.codex\`; uma regra \`write\` mais específica pode não reabri-las por causa da precedência das
-ACLs \`DENY\`. As entradas explícitas acima materializam o conjunto correto de capabilities,
-mantêm a escrita limitada ao repositório — inclusive em \`.git\` — e não concedem escrita ao restante de \`C:\\\`, ao perfil do
-usuário, a outros repositórios ou ao sistema operacional.
-
-### Segurança adicional
-
-\`zaip-aios-security\` possui a proteção mais forte porque os limites principais são aplicados
-pelo sandbox nativo:
-
-- uma tentativa de escrita fora do workspace é negada mesmo que uma instrução ou ferramenta
-  peça essa operação;
-- comandos alcançam apenas \`github.com\`; outros destinos permanecem negados;
-- \`~/.ssh\` pode ser alterado por fluxos Git ou de configuração explicitamente autorizados;
-- o impacto máximo de uma edição comum fica contido no repositório;
-- todas as camadas ZAIP descritas abaixo continuam ativas.
-
-Esse perfil é a opção de menor privilégio recomendada quando o trabalho cabe no workspace,
-especialmente para revisão, testes e manutenção delimitada. O perfil humano continua sendo
-\`zaip-aios-full-access\`; selecione \`zaip-aios-security\` explicitamente quando desejar contenção
-nativa. A escrita em \`~/.ssh\` e o egress para \`github.com\` ampliam o impacto potencial; nunca
-altere chaves, credenciais ou remotos sem autorização explícita.
-
-## \`zaip-aios-full-access\`
-
-### Acesso concedido
-
-No Windows, o perfil de acesso completo concede escrita em \`C:\\\` inteiro e rede completa:
-
-\`\`\`toml
-default_permissions = "zaip-aios-full-access"
-
-[permissions.zaip-aios-full-access.filesystem]
-":root" = "write"
-
-[permissions.zaip-aios-full-access.network]
-enabled = true
-mode = "full"
-
-[permissions.zaip-aios-full-access.network.domains]
-"*" = "allow"
-\`\`\`
-
-A configuração pode representar a raiz como \`:root\` ou \`C:\\\\\`. Neste ambiente, isso
-inclui tecnicamente:
-
-- o workspace e todos os seus arquivos;
-- \`.agents\`, \`.codex\` e \`.git\`;
-- outros repositórios em \`C:\\\`;
-- o perfil do usuário e seus arquivos;
-- diretórios de aplicações e do sistema;
-- qualquer destino de rede alcançável pelo host.
-
-O acesso continua sujeito às ACLs do Windows, políticas corporativas, arquivos em uso e
-privilégios da conta. O perfil não transforma o processo em administrador nem garante
-alteração de todo arquivo.
-
-### Riscos residuais
-
-\`zaip-aios-full-access\` continua sendo um perfil de maior risco. Um comando incorreto,
-conteúdo malicioso, dependência comprometida ou erro de escopo pode tentar:
-
-- alterar ou excluir arquivos fora do projeto;
-- modificar outros repositórios;
-- acessar dados do usuário;
-- executar operações destrutivas no sistema;
-- enviar dados pela rede;
-- ampliar o impacto de uma falha de supply chain.
-
-Ele é o default humano de permissão nativa, mas não substitui autorização. O hook complementar
-permanece default-deny para operações externas e não torna este perfil equivalente ao restrito.
-
-## Camadas que reduzem o risco do full access
-
-O acesso completo é mitigado por defesa em profundidade, mas nenhuma camada torna
-\`zaip-aios-full-access\` equivalente ao perfil restrito:
-
-1. **Autorização explícita do usuário:** mudanças externas, destrutivas, publicação, deploy,
-   gasto e mutações remotas exigem pedido explícito no turno atual.
-2. **Escopo do repositório:** \`AGENTS.md\`, Rules e skills limitam o trabalho ao objetivo e
-   proíbem inferir autoridade adicional a partir do acesso técnico.
-3. **Hook \`PreToolUse\` ativo nos dois perfis:** valida comandos e patches antes da execução; bloqueia escapes do
-   repositório, referências diretas a segredos, elevação, persistência de sistema, firewall,
-   antivírus, serviços, Git destrutivo, banco destrutivo e clientes remotos não autorizados.
-4. **Regras \`forbidden\`:** arquivos em \`.codex/rules/\` negam classes perigosas de comandos
-   mesmo quando o sandbox permitiria executá-las.
-5. **Política GitHub delimitada:** deploy e push seguem preflight, branch e remoto explícitos;
-   force-push, exclusão remota e publicação não solicitada permanecem proibidos.
-6. **Proteção de segredos:** tokens, chaves privadas, credenciais e valores de ambiente não
-   podem ser impressos, copiados, registrados em Runs nem incluídos em commits.
-7. **Lifecycle e telemetria sanitizada:** Runs registram atribuição, uso e resultado sem
-   autorizar ações nem persistir segredos.
-8. **Subagentes com menor privilégio:** agentes de revisão e auditoria permanecem read-only;
-   builders e integradores recebem escopos limitados.
-9. **Controles do sistema operacional:** ACLs, conta Windows, arquivos em uso e políticas do
-   host continuam sendo a última barreira técnica.
-
-Essas camadas reduzem probabilidade e impacto, mas podem conter bugs ou lacunas. Os limites
-nativos de \`zaip-aios-security\` oferecem proteção adicional ao negar escrita fora do workspace
-e egress para destinos diferentes de \`github.com\` antes que a operação alcance o sistema ou a rede.
-
-## Escolha do perfil
-
-Use \`zaip-aios-security\` quando:
-
-- todo o trabalho deve permanecer neste workspace;
-- \`.agents\` e \`.codex\` precisam ser editáveis;
-- comandos precisam, no máximo, alcançar \`github.com\` para operações Git/SSH autorizadas;
-- menor privilégio é desejado.
-
-Use \`zaip-aios-full-access\` como default humano quando:
-
-- for necessário corrigir a própria configuração de permissões;
-- uma operação autorizada precisar de um caminho fora do workspace;
-- o bloqueio do perfil restrito tiver sido diagnosticado e não houver alternativa limitada.
-
-Não use full access apenas para evitar investigar uma negação.
-
-## Validação obrigatória
-
-Após alterar qualquer perfil:
-
-1. Confirme que \`default_permissions\` seleciona exatamente o perfil desejado.
-2. Confirme que não existe \`sandbox_mode\` em outra configuração carregada.
-3. Reinicie completamente o Codex.
-4. Com \`zaip-aios-security\`, valide escrita no workspace, em \`.agents\` e em \`.codex\`.
-5. Quando uma operação Git estiver autorizada, confirme que \`.git\` aceita a alteração de índice necessária, sem ampliar o acesso fora do repositório.
-6. Confirme que escrita fora do workspace é negada sem criar arquivo externo.
-7. Confirme que Git/SSH alcança \`github.com\` somente após autorização de deploy e que outros destinos continuam negados.
-8. Execute uma captura ZAIP e confirme \`run.started\`, \`usage.recorded\` e \`run.finished\`.
-9. Com full access, confirme a seleção do perfil sem realizar probes destrutivos ou gravar em
-   caminhos externos apenas para demonstrar alcance.
-
-O sandbox e as ACLs são materializados na inicialização; o teste funcional precisa ocorrer
-em uma nova sessão.
-
-Se uma versão anterior com \`:workspace\` ou \`:workspace_roots\` já tiver sido executada e o
-reinício continuar negando \`.agents\`/\`.codex\`, feche todas as sessões Codex, faça backup de
-\`~/.codex/cap_sid\`, mova somente o arquivo ativo para fora desse caminho e reinicie o Codex.
-O runtime criará novos capability SIDs; os \`DENY\` antigos ficarão inertes por não pertencerem
-ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
-
-## Arquivos da política
-
-| Arquivo | Papel |
-| --- | --- |
-| \`~/.codex/config.toml\` | seleção e definição efetiva dos perfis |
-| \`.codex/config.toml\` | projeção versionada dos perfis e hooks |
-| \`.codex/zaip-aios-security.config.toml\` | configuração dedicada do perfil restrito |
-| \`.codex/zaip-aios-full-access.config.toml\` | configuração dedicada do perfil completo |
-| \`.agents/skills/zaip-skill-security/SKILL.md\` | avaliação dos riscos e controles |
-| \`.agents/skills/zaip-skill-setup/SKILL.md\` | instalação, correção e validação dos perfis |
-| \`.codex/hooks/zaip-pre-tool-use.mjs\` | guarda adicional de comandos |
-| \`.codex/rules/\` | decisões determinísticas de comandos permitidos e proibidos |
-| este guia | contrato operacional e comparação dos perfis |
-`,p="# Observabilidade e custos\n\n1. Selecione o Run pelo ID.\n2. Verifique duracao, tokens, custo, retries e retrabalho.\n3. Compare aceite planejado com evidencia produzida.\n4. Identifique gates lentos, contexto excessivo e chamadas repetidas.\n5. Agregue tendencias sem expor prompts ou segredos sensiveis.\n6. Converta achados recorrentes em Rule, Requirement ou melhoria de skill.\n\nRun e o envelope da chamada do `zaip-agent-orchestrator`; `parent_run_id` nulo identifica esse nivel. Sub-Run e a chamada de qualquer subagente e possui `parent_run_id`. Ambas fixam modelo e effort e agregam Calls, segmentos de uso, tokens e custo. Calls nao possuem tela ou lifecycle proprio. Operacao e Monitor de Custos apresentam “Chamadas do agente orquestrador” e “Chamadas de subagentes”; a Execution soma as duas categorias, finalizadores e Calls sem dupla contagem. Cada segmento de uso possui uma chave de origem e so pode ser atribuido uma vez; uma correcao de duplicidade registra supersessao e preserva o evento historico. Inspecione `run_purpose`, pai e `agent_name`; agentes do catalogo usam `zaip-agent-*`. Diferencie status tecnico da chamada de agente e resultado terminal da Task. Reconcilie lifecycle globalmente apenas por comando humano explicito ou pelo popup confirmado; isso nao ocorre em cada turno nem ao abrir o dashboard.\n\nA criação explícita de PRD/SPEC vincula a Run de definição e o `creation_run_id` ao macro. Duração, tokens e custo aparecem no PRD/SPEC antes de existirem Tasks somente quando foram observados ou reconciliados; valores indisponíveis permanecem `null`. Pensar sem criar permanece apenas em Conversas. Nunca atribua telemetria indisponível nem transforme ausência em zero.\n",m=`# Instalacao e upgrade
-
-1. Verifique versao atual e estado limpo ou conscientemente preservado.
-2. Execute doctor/integrity antes da mudanca.
-3. Faça dry-run da instalacao, migracao ou upgrade.
-4. Revise arquivos gerenciados, publicos e preservados.
-5. Aplique, valide adapters e rode gates.
-6. Teste rollback e confirme a versao final.
-
-\`framework.lock.yaml\` e relevante neste fluxo; nao o carregue no trabalho comum.
-`,h=`# Boas praticas
-
-- Comece pelo resultado e aceite, nao pela ferramenta.
-- Mantenha dominio independente de infraestrutura.
-- Faça mudancas pequenas, reversiveis e rastreaveis.
-- Valide cedo com testes deterministas e focados.
-- Prefira configuracao explicita a convencoes ocultas.
-- Leia contexto sob demanda e preserve o budget de tokens.
-- Trate documentacao, observabilidade e rollback como parte da entrega.
-- Nunca termine a Run raiz sem o Sub-Run finalizador ou com Task em executing/verifying.
-- Nao terminalize SPEC/PRD por causa do resultado isolado de uma Task filha.
-- Prefira reconciliacao manual sob demanda; hooks de escrita fazem checagem local sem varredura global.
-- Use uma SPEC por padrão; divida somente capacidades realmente independentes e paralelizáveis.
-- Não crie Tasks durante definição: mostre blueprints compactos e materialize somente em \`ready|execute\`.
-- Resolva verbos de lifecycle pelo alvo e status persistido, nunca por palavra isolada.
-`,g="# Troubleshooting\n\n1. Reproduza o problema com o menor comando possivel.\n2. Leia a mensagem completa e identifique o primeiro erro causal.\n3. Rode doctor, validadores focados e `git diff --check`.\n4. Confira versoes, paths, encoding, variaveis e arquivos gerenciados.\n5. Compare `manifest.json`, `summary.json`, índices e chunks de `records/lifecycle`, sem varrer records.\n6. Corrija a causa, repita a reproducao e depois os gates completos.\n\nSe uma Task estiver presa em executing/verifying, use o popup Reconciliar. O reparo aceita `task_complete` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. Nao habilite reconciliacao automatica por turno ou na abertura do dashboard.\n\nSe o problema for de instalacao ou integridade, consulte `framework.lock.yaml`.\n\nSe “finalizar” tentou entregar um PRD `draft`, confira adapters/skills: o correto é lapidar e mover para `ready`. Se uma DAG nova cruza SPECs, una as capacidades em uma SPEC e mantenha a dependência entre suas Tasks. PRD cancelado não reabre; crie sucessor `rework`.\n",_="# Tools e setup do Codex\n\n1. Peça ao agente para listar ou ativar uma tool; ele usa `$zaip-skill-tool-setup`.\n2. A skill lê somente catálogo e manifesto aplicável.\n3. MCP confiável é registrado desabilitado em `.codex/config.toml` e validado antes da ativação.\n4. API sem MCP confiável aciona `$zaip-skill-api-to-mcp` para gerar um adaptador seguro.\n5. Secrets nunca são coladas no chat; nomes ficam em `.agents/.env.example` e valores em armazenamento local ignorado.\n6. Alterações de configuração devem ser reversíveis e preservar preferências existentes.\n\nAtive por padrão apenas integrações públicas, read-only e sem autenticação, como documentação oficial. Browser/Playwright deve ser opt-in do perfil de desenvolvimento, pois inicia processos e amplia a superfície operacional.\n\n## MCP local gerado de API\n\n1. Modele um `adapter.yaml` a partir de documentação oficial; use o exemplo da skill API-to-MCP.\n2. Execute `scaffold-local-mcp.mjs` para gerar `definition.json`, `server.mjs` e `cli.mjs`.\n3. Rode `node .agents/tools/servers/<id>/cli.mjs doctor`.\n4. Faça chamadas read-only com `cli.mjs call <tool> '<json>'`.\n5. Gere um preview do Codex com `configure-local-mcp.mjs <id>`.\n6. Revise e aplique com `--write`; use `--enable` somente quando o doctor estiver pronto.\n\nO servidor usa STDIO, não abre porta e não exige deploy. Escritas ficam bloqueadas sem aprovação e `ZAIP_ALLOW_MCP_WRITES=1`.\n\n## Documentacao OpenAI\n\nO perfil default habilita `openaiDeveloperDocs` em `.codex/config.toml`, sem credencial e em modo read-only. Perguntas sobre OpenAI API, modelos, SDKs, Codex ou MCP devem acionar `$zaip-skill-openai-docs`, pesquisar o MCP oficial e citar a pagina consultada.\n",v="# Lifecycle e reconciliacao\n\n## Entradas\n\n- Conversation: pergunta, feedback ou analise read-only; cria Run intake e nenhuma Task.\n- Task avulsa: resultado independente. Pedido de acao entra em Execucao antes da primeira escrita; pedido apenas de preparacao pode parar em Pronto para Executar.\n- SPEC: planejamento tecnico de multiplas Tasks; draft fica em Planejamento.\n- PRD: definicao de produto; draft fica em Definicao.\n\nPensar/explorar PRD ou SPEC é Conversation. Criar explicitamente persiste macro, SPECs e PreparedPlan `draft`, atribui telemetria e mantém apenas blueprints de Tasks. `ready` é o único ponto que materializa Tasks/Changes/Execution sem iniciar; `execute` materializa e inicia.\n\n## Colunas\n\n| Coluna | Entidades |\n|---|---|\n| Definicao | somente PRD draft |\n| Planejamento | somente SPEC draft |\n| Pronto para Executar | PRD/SPEC ready e Task avulsa nao iniciada |\n| Execucao | Task executing e SPEC/PRD active |\n| Verificacao | Task verifying ou macro nos gates parentais |\n| Finais | completed/delivered, blocked, failed ou cancelled |\n\n## Execution, Runs, Sub-Runs e Calls\n\n- Execution coordena a DAG de uma ou mais Tasks.\n- Run e a chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id` nulo.\n- Sub-Run e cada chamada de subagente; possui `parent_run_id` e compartilha o mesmo ledger `RUN-*`.\n- Novas gravacoes usam somente `run_role: intake|orchestrator|subagent`; `owner|contributor` sao valores historicos aceitos apenas na leitura e normalizados imediatamente.\n- `run_purpose` distingue `orchestration`, `execution`, `review`, `audit` e `finalization`.\n- cada Run/Sub-Run fixa agente, modelo e effort; mudanca deliberada abre outra chamada de agente.\n- Calls e ferramentas sao eventos internos; quantidade, tokens e custo ficam agregados na Run/Sub-Run, sem tela propria.\n\nO ultimo filho de qualquer Execution e sempre o `zaip-agent-finalizer`. Ele aguarda todos os outros descendentes, cria uma barreira contra filhos posteriores e retorna uma decisao terminal restrita para a CLI aplicar. Toda Execution exige antes ao menos um executor elegivel pelas capacidades do catalogo. Status tecnico da chamada de agente e resultado do trabalho sao independentes.\n\n`blocked` e retomavel com `task resume`; `failed` exige `task rework` na mesma Task e nova tentativa. `completed` e `cancelled` sao imutaveis. Interromper geracao bloqueia; cancelar a Task explicitamente cancela.\n\n`finalize|conclua` em macro `draft|ready` significa lapidar e deixar pronto; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. `implemente` é sensível ao estado; `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado gera sucessor vinculado com tag `rework`.\n\n## SPEC e PRD\n\nAo iniciar a primeira Task filha, os pais ficam active/Execucao e permanecem assim entre Runs. Task bloqueada ou falhada nao bloqueia automaticamente o pai. Depois que todas as Tasks concluem, SPEC/PRD entram em verificacao parental; apenas gates de integracao, Acceptance Criteria, outcomes e Evidence entregam o macro.\n\nNovas SPECs de um PRD não possuem dependências entre si: são capacidades paralelizáveis e verificáveis isoladamente. Dependências e ordem ficam nas Tasks da mesma SPEC; integração final é gate parental.\n\n## Reconciliacao\n\nO popup Reconciliar chama `run reconcile --open` somente depois da confirmacao humana. Nao existe varredura ao abrir o dashboard, por turno ou por intervalo.\n\nO reparo e idempotente: `task_complete` local exato permite tentar conclusao; gate insuficiente usa blocked; Run sem invocacao ativa por dez minutos usa failed; cancelled nunca e inferido. Projecoes exibem o status persistido e nao revivem Task terminal por atividade local obsoleta.\n\n## Mutacoes\n\nCodigo, documentacao e configuracao exigem Task materializada e Run raiz ativa antes da escrita. Sao isentos deploy/publicacao Git sem mudanca de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e temporarios descartaveis. O hook pre-write faz checagem local do turno, sem tokens e sem reconciliacao global.\n",y=`# Como o custo é calculado
-
-Cada valor começa na telemetria de uma chamada LLM. O dashboard não estima uso ausente: dado indisponível continua indisponível.
-
-## 1. Separe os componentes de uso
-
-- **Tokens de input** incluem instruções, histórico, contexto, ferramentas e a mensagem atual.
-- **Tokens de cache** fazem parte do input, não são uma quantidade extra. Eles são subtraídos do input antes da aplicação da sua própria tarifa.
-- **Tokens de output** são tudo que o modelo gerou.
-- **Tokens de reasoning** fazem parte do output. O output é cobrado uma única vez, então reasoning não cria uma segunda cobrança.
-
-## 2. Aplique as tarifas publicadas do modelo
-
-O modelo e o tier de serviço escolhidos definem a tabela de tarifas. Para uma chamada, o total em USD é:
-
-| Componente | Cálculo |
-| --- | --- |
-| Input faturável | \`(input - cache) / 1.000.000 × tarifa de input\` |
-| Cache | \`cache / 1.000.000 × tarifa de cache\` |
-| Output | \`output / 1.000.000 × tarifa de output\` |
-
-O dashboard soma esses componentes uma única vez. Quando uma tarifa publicada não existe, ela permanece indisponível em vez de ser inventada.
-
-## 3. Considere contexto, velocidade e esforço
-
-Acima do limite de contexto longo de um modelo, o multiplicador publicado de input também vale para cache e o multiplicador de output vale para todo o output. Priority/Fast usa a sua tabela de tarifas publicada, quando disponível. O multiplicador exibido é apenas uma comparação com Standard, nunca uma cobrança extra.
-
-O esforço não possui multiplicador direto de preço. Ele só pode aumentar o custo indiretamente quando aumenta reasoning, output ou ciclos de execução registrados.
-
-## 4. Converta para a moeda selecionada
-
-O total da chamada é calculado primeiro em USD. Em BRL, é usada a cotação registrada no período relevante; a cotação atual é mantida separadamente para conversões atuais. Mudar a moeda de exibição nunca altera a telemetria de tokens nem o cálculo em USD.
-`,b=e(),x=`# ZAIP-AIOS (6 Squads + 23 Agents)
-
-## Visão rápida
-
-O ZAIP-AIOS é um sistema operacional para execução autônoma de trabalho com agentes de IA, que coordena 23 agentes especializados, organizados em 6 squads, dentro do Codex.
-
-Os agentes trabalham de forma integrada e em cadeia: planejam, executam, revisam, testam e validam o trabalho, acionando automaticamente o próximo especialista quando necessário. Em vez de o usuário precisar solicitar cada alteração, teste, revisão ou correção separadamente, o ZAIP-AIOS conduz o fluxo de ponta a ponta até que os critérios definidos sejam atendidos.
-
-Essa abordagem reduz intervenções manuais, acelera o ciclo de execução e pode gerar uma redução de 34% a 62% no consumo de tokens, ao distribuir cada etapa para agentes especializados e evitar interações, contexto e retrabalho desnecessários.
-
-Embora tenha nascido com forte foco em desenvolvimento de software, o ZAIP-AIOS também executa demandas de Operações, Growth, Marketing, Branding e Vendas, permitindo coordenar diferentes tipos de trabalho dentro da mesma arquitetura autônoma, sem consumo direto de APIs de IA e sem necessidade de infraestrutura própria em VPS.
-
-<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">
-
-Na prática, o sistema decompõe demandas complexas, organiza o trabalho, seleciona os agentes mais adequados, coordena dependências, acompanha a execução e verifica a qualidade antes de considerar uma entrega concluída.
-
-O Dashboard centraliza a operação em uma única visão, reunindo Tasks, SPECs e PRDs, além de dependências, bloqueios, tempo de execução, consumo de tokens, custos, revisões e evidências produzidas ao longo do processo.
-
-<img src=".agents/config/src/dashboard_pt_1_visao_geral.png" alt="Dashboard ZAIP-AIOS, Visão Geral" width="100%">
-
-Em uma amostra comparativa de tarefas executadas de forma autônoma, o ZAIP-AIOS apresentou uma redução aproximada de 34% no custo médio por tarefa e 62% no custo médio por hora.
-
-A comparação considera o ciclo completo de trabalho, planejamento, execução, testes, revisões e documentação —, e os resultados devem ser interpretados dentro dos limites da amostra analisada.
-
-<img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Análise comparativa: custo médio por hora caiu de R$ 410 para R$ 154" width="900">
-
-A fonte da verdade permanece no Git. Requisitos, decisões, implementações, testes, revisões e evidências são versionados no repositório e preservados no histórico publicado no GitHub.
-
-O Dashboard utiliza um banco de dados local, descartável e reconstruível, apenas como camada de consulta e visualização. Nenhuma informação crítica depende exclusivamente dele.
-
-No ZAIP-AIOS, uma Task não é considerada concluída apenas porque um agente terminou sua execução. Ela só é encerrada quando existem evidências objetivas de que os Critérios de Aceite e os requisitos de qualidade foram atendidos.
-
-## Comece por aqui
-
-| Se você quer… | Comece por… |
-| --- | --- |
-| Instalar e obter o primeiro resultado | [Instalação em um comando](#instalação-em-um-comando) |
-| Conhecer os resultados observados | [Economia medida](#economia-medida-e-meta-central-por-tarefa) |
-| Acompanhar trabalho, custos e qualidade | [Dashboard Local](#dashboard-local) |
-| Fazer uma alteração pontual | [Três formas de executar](#três-formas-de-executar) |
-| Planejar uma entrega técnica ou de produto | [PRD como interface de autonomia](#prd-como-interface-de-autonomia) |
-| Entender o método | [Método ZAIP em seis etapas](#método-zaip-em-seis-etapas) |
-| Conhecer os agentes especializados | [Personas e roteamento de agentes](#personas-e-roteamento-de-agentes) |
-| Consultar os contratos técnicos | [Referência técnica e operacional](#referência-técnica-e-operacional) |
-| Manter o framework | [Desenvolvimento do framework](#desenvolvimento-do-framework) |
-| Configurar permissões com segurança | [Segurança com perfis de permissão](#segurança-com-perfis-de-permissão) |
-
-## Instalação em um comando
-
-Com Node.js 22 ou mais recente e Git disponíveis, a instalação acontece na raiz do repositório que receberá o ZAIP-AIOS:
-
-\`\`\`bash
-npx @zaip-ai/cli@latest init
-\`\`\`
-
-O sufixo \`@latest\` instala a release pública atual sem fixar o README a uma versão específica. O CLI encontra a raiz Git mesmo quando o comando é iniciado em uma subpasta, valida o template antes de escrever e interrompe a instalação se detectar conflito com arquivo pertencente ao usuário. O mesmo comando pode ser executado novamente para receber arquivos novos e atualizar adapters gerenciados sem apagar o histórico do projeto.
-
-Cada release do CLI leva seu próprio template verificado. A árvore documentada neste README representa o estado atual do repositório-fonte; uma funcionalidade recém-integrada passa a chegar pelo mesmo comando assim que a release correspondente é publicada.
-
-O instalador cria [\`.agents\`](.agents/) com regras, requisitos, skills, documentação operacional, catálogo de ferramentas, Dashboard, design system e estado Git-native do lifecycle. Também instala os adapters \`AGENTS.md\` e \`CLAUDE.md\`, as skills de descoberta em \`.codex/skills/zaip-aios/SKILL.md\` e \`.claude/skills/zaip-aios/SKILL.md\`, a configuração de projeto \`.codex/config.toml\` e as configurações equivalentes do Claude. Todos apontam para a mesma fonte canônica, preservando o Codex como experiência principal sem acoplar PRDs, SPECs, Tasks e evidências a um único host.
-
-Depois da instalação, o [índice operacional](.agents/zaip-aios/INDEX.md) organiza os guias de primeiros passos, execução, revisão, custos, ferramentas, diagnóstico e atualização.
-
-## Como as camadas se complementam
-
-| Tipo | Nome | Responsabilidade |
-| --- | --- | --- |
-| **Modelo de IA (AI Model)** | **GPT-5.6 (padrão)** | Modelo principal para raciocínio, programação, uso de ferramentas, coordenação de agentes e execução de tarefas complexas. A configuração permanece aberta para testes, comparação ou substituição por outros modelos. |
-| **Ferramenta (AI Harness)** | **Codex (padrão)** | Harness oficial que conecta o modelo LLM ao terminal, ferramentas, subagentes, worktrees, sandbox, hooks, skills e navegador. Por estar alinhado ao treinamento do modelo, oferece maior otimização, previsibilidade e aproveitamento de suas capacidades. |
-| **Metodologia (AI Coding)** | **ZAIP-AIOS** | Sistema Git-native de engenharia autônoma e multiagente. Converte PRDs e SPECs em Tasks, DAGs e Changes executáveis, automatiza testes e reviews e mantém decisões, execuções, evidências, custos e mudanças rastreáveis no Git. |
-
-O modelo fornece a inteligência, o Codex oferece o ambiente oficial de execução e o ZAIP-AIOS acrescenta método, governança e memória verificável. Essa combinação define **o que deve ser feito, como o trabalho deve ser organizado, quais regras precisam ser respeitadas e quais provas permitem declará-lo concluído**. A experiência de referência é otimizada para GPT-5.6 e Codex, enquanto modelos e hosts alternativos permanecem disponíveis para comparação e compatibilidade por meio de artefatos portáveis.
-
-## Personas e roteamento de agentes
-
-O ZAIP-AIOS reúne 23 agentes especializados para que cada demanda seja conduzida pela competência mais adequada. O objetivo não é usar todos em cada entrega, mas formar o menor conjunto capaz de executar, revisar e comprovar o resultado com qualidade.
-
-As identidades técnicas permanecem separadas das personas visíveis. Assim, nomes e cargos podem ser apresentados e configurados no Dashboard sem comprometer os contratos internos de roteamento. A escolha considera a decisão ou o resultado primário, especialidade, escopo e risco; referências e insumos apoiam o trabalho, mas não mudam sozinhos o executor. Autoria, contexto e histórico permanecem rastreáveis.
-
-### Os 23 agentes
-
-| Foto | # | Persona / função | Especialidade |
-| :---: | ---: | --- | --- |
-| <img src=".agents/config/src/1%20-%20Dave%20-%20Product%20Owner.png" alt="Dave, Product Owner" width="400"> | 1 | Dave / Product Owner | Resolve DAG e delega |
-| <img src=".agents/config/src/2%20-%20Rafa%20-%20Tech%20Lead.png" alt="Rafa, Tech Lead" width="400"> | 2 | Rafa / Tech Lead | Entrega genérica, SPEC e dashboard/local |
-| <img src=".agents/config/src/3%20-%20Leo%20-%20Software%20Engineer.png" alt="Leo, Software Engineer" width="400"> | 3 | Leo / Software Engineer | Task genérica ponta a ponta |
-| <img src=".agents/config/src/4%20-%20Bia%20-%20Product%20Manager.png" alt="Bia, Product Manager" width="400"> | 4 | Bia / Product Manager | Criação/refino de PRD e análise de produto |
-| <img src=".agents/config/src/5%20-%20Gui%20-%20Quality%20Assurance%20Lead.png" alt="Gui, Quality Assurance Lead" width="400"> | 5 | Gui / Quality Assurance Lead | Resultado terminal restrito |
-| <img src=".agents/config/src/6%20-%20Nanda%20-%20Principal%20Engineer.png" alt="Nanda, Principal Engineer" width="400"> | 6 | Nanda / Principal Engineer | Revisão independente |
-| <img src=".agents/config/src/7%20-%20Dani%20-%20Integration%20Engineer.png" alt="Dani, Integration Engineer" width="400"> | 7 | Dani / Integration Engineer | Integração e gates combinados |
-| <img src=".agents/config/src/8%20-%20Ana%20-%20Quality%20Auditor.png" alt="Ana, Quality Auditor" width="400"> | 8 | Ana / Quality Auditor | Auditoria independente |
-| <img src=".agents/config/src/9%20-%20Lia%20-%20Technical%20Writer.png" alt="Lia, Technical Writer" width="400"> | 9 | Lia / Technical Writer | Resumo fiel, análise de transcrição e documentação fundamentada em fontes |
-| <img src=".agents/config/src/10%20-%20Gabi%20-%20Data%20Analyst.png" alt="Gabi, Data Analyst" width="400"> | 10 | Gabi / Data Analyst | Análise de dados |
-| <img src=".agents/config/src/11%20-%20Tati%20-%20Refactoring%20Specialist.png" alt="Tati, Refactoring Specialist" width="400"> | 11 | Tati / Refactoring Specialist | Refatoração, migração e modularização seguras |
-| <img src=".agents/config/src/12%20-%20Doug%20-%20Frontend%20Developer.png" alt="Doug, Frontend Developer" width="400"> | 12 | Doug / Frontend Developer | Frontend e acessibilidade conforme \`DESIGN.md\` |
-| <img src=".agents/config/src/13%20-%20Will%20-%20Backend%20Developer.png" alt="Will, Backend Developer" width="400"> | 13 | Will / Backend Developer | API, backend e módulos |
-| <img src=".agents/config/src/14%20-%20Jonny%20-%20Website%20Developer.png" alt="Jonny, Website Developer" width="400"> | 14 | Jonny / Website Developer | Sites e landing pages, SEO, GEO e preparação para agentes |
-| <img src=".agents/config/src/15%20-%20Manu%20-%20Product%20Designer.png" alt="Manu, Product Designer" width="400"> | 15 | Manu / Product Designer | \`DESIGN.md\`, Design System, tokens e catálogo |
-| <img src=".agents/config/src/16%20-%20Dan%20-%20Cloud%20Engineer.png" alt="Dan, Cloud Engineer" width="400"> | 16 | Dan / Cloud Engineer | Infraestrutura cloud, Terraform, Docker e ambientes |
-| <img src=".agents/config/src/17%20-%20Luis%20-%20Security%20Auditor.png" alt="Luiz, Security Auditor" width="400"> | 17 | Luiz / Security Auditor | Auditoria técnica e independente de segurança |
-| <img src=".agents/config/src/18%20-%20Lucia%20-%20Marketing%20Analyst.png" alt="Lucia, Marketing Analyst" width="400"> | 18 | Lucia / Marketing Analyst | Planejamento de marketing, copy e preparação de ativos |
-| <img src=".agents/config/src/19%20-%20Renata%20-%20Compliance%20Specialist.png" alt="Renata, Compliance Specialist" width="400"> | 19 | Renata / Governance & Compliance Specialist | Artefatos internos de RH, jurídico operacional, políticas, privacidade, fornecedores e riscos |
-| <img src=".agents/config/src/20%20-%20Clara%20-%20Operations%20Specialist.png" alt="Clara, Operations Specialist" width="400"> | 20 | Clara / Operations Generalist | Documentos, apresentações, planilhas, processos e comparativos delimitados fora de especialidades obrigatórias |
-| <img src=".agents/config/src/21%20-%20Sarah%20-%20Branding%20Specialist.png" alt="Sarah, Branding Specialist" width="400"> | 21 | Sarah / Branding Specialist | Estratégia e governança de marca, Brandbook, arquétipos, diferencial semântico e arquitetura de marca |
-| <img src=".agents/config/src/22%20-%20Aaron%20-%20Sales%20Specialist.png" alt="Aaron, Sales Specialist" width="400"> | 22 | Aaron / Sales Specialist | Processo comercial interno, qualificação, playbooks, scripts e handoffs entre SDR e closer |
-| <img src=".agents/config/src/23%20-%20Robert%20-%20Growth%20Strategist.png" alt="Robert, Growth Strategist" width="400"> | 23 | Robert / Growth Strategist | Estratégia de crescimento, RevOps, experimentos e recomendações orientadas por dados e impacto financeiro |
-
-O [Catálogo de agentes](docs/AGENT-CATALOG.md) reúne as especialidades e responsabilidades dos agentes disponíveis no ZAIP-AIOS.
-
-### Squads organizacionais
-
-<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">
-
-Os seis squads tornam a estrutura de responsabilidades fácil de visualizar: **Product** (Dave, Bia e Manu), **Admin & Operations** (Clara, Renata e Lia), **Development** (Rafa, Leo, Jonny, Will, Doug e Tati), **Delivery Assurance** (Nanda, Gui, Ana e Dani), **Infra & Security** (Dan e Luiz) e **Growth — Sales, Marketing and Branding** (Robert, Gabi, Lucia, Sarah e Aaron).
-
-Essa é uma visão organizacional, não uma regra de roteamento. O orquestrador seleciona o agente por capability, escopo declarado, risco e write scopes da Task; pertencer ao mesmo squad não concede acesso, não substitui a seleção canônica e não obriga colaboração.
-
-Cada demanda pode começar como uma Task, uma SPEC ou um PRD. Em qualquer entrada, a intenção é transformada em trabalho estruturado, com objetivo, escopo, critérios de qualidade e etapas rastreáveis.
-
-O Codex permanece como ambiente de execução, enquanto o ZAIP-AIOS acrescenta organização, governança e visibilidade ao ciclo de desenvolvimento. Pelo Dashboard, é possível acompanhar o avanço das entregas, suas dependências, bloqueios e resultados.
-
-O sistema utiliza os tokens disponíveis na conta ChatGPT/Codex e apresenta, no Dashboard, uma estimativa do custo equivalente de API para fins de comparação e planejamento.
-
-## Dashboard Local
-
-O Dashboard transforma o histórico técnico do ZAIP-AIOS em uma visão operacional clara. Em um só lugar, ele mostra o trabalho em andamento, os custos observados, a cobertura de qualidade, os bloqueios e a relação entre intenção, execução e resultado.
-
-<img src=".agents/config/src/dashboard_pt_1_visao_geral_este_mes.png" alt="Dashboard ZAIP-AIOS, Visao Geral Mes" width="100%">
-
-Os registros Git-native continuam sendo a fonte oficial. Tudo o que aparece nas telas pode ser reconstruído a partir dos arquivos canônicos e da configuração do projeto, sem criar uma base paralela ou dependência externa de infraestrutura.
-
-<strong>Como funciona a projeção local do Dashboard</strong>
-
-Os registros ZAIP canônicos permanecem na estrutura padrão em \`.agents/records\`. Para acelerar consultas e visualizações, o Dashboard reconstrói um SQLite descartável como *read model*. Esse arquivo não é fonte de verdade nem armazenamento canônico: é apenas uma projeção local reconstruível.
-
-Não é preciso instalar ou abrir servidor SQLite, DBeaver ou banco externo. O Node.js 22 já inclui \`node:sqlite\` para esse uso local.
-
-
-### Kanban
-
-Organiza PRDs, SPECs e Tasks por estágio, destacando execução, verificação, conclusão, criticidade, tempo, tokens e custo observado.
-
-<img src=".agents/config/src/dashboard_pt_2_kanban.png" alt="Dashboard ZAIP-AIOS, Kanban" width="100%">
-
-As visões Trabalho (Kanban) e Trabalho (Lista) permitem alternar entre leitura por estágio e comparação detalhada. Ambas preservam os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas, facilitando a análise de status, origem, risco, Runs, Sub-Runs, tempo, tokens, custo e cobertura. Cada item pode ser aberto para investigar bloqueios e consultar seu histórico rastreável.
-
-### Monitor de Custos
-
-Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero.
-
-<img src=".agents/config/src/dashboard_pt_3_monitor_custos.png" alt="Dashboard ZAIP-AIOS, Monitor de Custos" width="100%">
-
-O Monitor consolida tokens, tempo, custo e cobertura por Run, Task, SPEC e PRD. Isso permite comparar conversa, planejamento, execução, trabalho novo e rework, além de identificar médias e concentrações de consumo por dia, mês ou ano.
-
-Quando o Codex utiliza os tokens ou a franquia da conta em vez de cobrar uma API, o módulo calcula, sempre que há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. A estimativa apoia gestão e comparação, mas nunca é apresentada como cobrança real. Valores não observados continuam \`unknown\`, sem serem convertidos artificialmente em zero.
-
-**Contrato técnico da telemetria**
-
-A telemetria do Codex usa spool local sanitizado, um \`InvocationSummary\` por invocação e chunks com
-manifestos mensais rastreados pelo Git. Consultas com período usam os manifestos primeiro e mantêm
-fallback para a projeção de Run quando não existe resumo aplicável. Cobertura incompleta continua
-explícita em cada métrica. A [Telemetria Git-native do Codex](docs/TELEMETRIA-GIT-NATIVE.md)
-documenta contratos, armazenamento, integridade, recuperação e limites do rollout.
-
-
-### Rastreabilidade
-
-Relaciona intenção, planejamento, execução, decisões, validações e evidências para explicar de onde cada resultado veio.
-
-<img src=".agents/config/src/dashboard_pt_4_rastreabilidade.png" alt="Dashboard ZAIP-AIOS, Rastreabilidade" width="100%">
-
-Correlaciona PRD, Requirements, SPEC, Change, Task, Execution, Runs, Decisions, testes, reviews, evals e Evidence em um grafo lógico de rastreabilidade. A visão detalha as seis etapas do método e mostra quais documentos e provas sustentam cada resultado. Cada registro recebe identificador, data e hora quando faz parte do lifecycle ou da telemetria; as evidências permanecem vinculadas e a cronologia também é preservada pelo Git. Isso permite auditoria, retomada, análise de rework e comparação entre intenção e execução. Projeções podem ser reconstruídas e otimizadas; a compactação Git-native da telemetria preserva IDs, relações, métricas, cobertura e hashes sem versionar prompts ou respostas.
-
-## O custo que importa: concluir a tarefa
-
-O preço de uma chamada ou de um modelo não representa sozinho o custo real do desenvolvimento com IA. Uma entrega pode envolver entendimento, leitura de contexto, implementação, testes, correções, revisão, validação e documentação. Por isso, o ZAIP-AIOS mede **o custo para concluir o trabalho**, acompanhando Runs, fases e rework por Task, SPEC e PRD.
-
-Uma forma prática de analisar o custo total é:
-
-\`\`\`text
-custo da tarefa concluída = modelo + ferramentas + tempo humano + rework + custo de defeitos
-\`\`\`
-
-## PRD como interface de autonomia
-
-O PRD permite governar uma iniciativa completa sem transformar cada decisão técnica em uma nova etapa manual. Ele registra o resultado esperado, organiza as entregas necessárias e mantém espaço para revisão humana antes da execução.
-
-Quando o usuário diz **“Me ajude a pensar sobre um PRD”**, o sistema mantém a interação como uma conversa de planejamento.
-
-Quando diz **“Crie um PRD”**, a IA faz até cinco perguntas importantes por turno, por no máximo três turnos. Depois, cria:
-
-- um PRD em estado \`draft\`
-- as SPECs técnicas necessárias
-- um \`PreparedPlan\`
-- uma lista resumida de Tasks
-
-As decisões técnicas que puderem ser delegadas são assumidas e registradas pela IA.
-
-**Detalhes de planejamento, decomposição e comandos**
-
-### Organização das SPECs
-
-Por padrão, cada PRD utiliza apenas uma SPEC, buscando economia.
-
-Uma nova SPEC só deve ser criada quando existir uma capacidade que possa ser implementada e validada de forma independente e paralela. Quando existe dependência entre partes do trabalho, elas permanecem na mesma SPEC e são organizadas pela DAG de Tasks.
-
-No runtime atual, um PRD materializa uma Execution-filho determinística para cada SPEC elegível: suas dependências permanecem dentro da SPEC e seus write scopes não conflitam com nenhum outro ramo. Cada filha executa com coordinator, estado, quota de orçamento e handoff próprios, sob uma fila limitada pelo paralelismo efetivo e por um ledger parental único de invocações; a Execution do PRD aguarda os estados terminais, integra os candidatos no handoff parental e só então aplica validação cross-SPEC e finalização. SPECs com dependência externa ou conflito de escopo permanecem na DAG global coordenadora.
-
-Antes de o PRD chegar ao estado \`ready\`, as Tasks são apenas definições de trabalho, ainda sem execução.
-
-Os comandos **“Deixe pronto para executar”**, **“Finalize o PRD”** ou **“Conclua o PRD”** criam as Tasks, Changes e Executions no estado \`planned\`, mas não iniciam a implementação.
-
-O comando **“Execute”** atua sobre o menor item informado pelo usuário, que pode ser uma Task, uma SPEC ou o PRD completo.
-
-### Limite de decomposição
-
-A escala de 1 a 5 define o limite de decomposição do PRD. Ela não representa uma meta obrigatória.
-
-* Nível 1 cobre um único fluxo vertical
-* Níveis 2 a 4 exigem capacidades independentes, com contratos e escopos de escrita separados
-* Nível 5 deve ser usado apenas em casos excepcionais com cinco implementações semelhantes e independentes
-
-Quando existe dependência entre capacidades, o trabalho deve permanecer na mesma SPEC. Projetos com mais de cinco capacidades devem ser divididos em outros PRDs ou registrar uma exceção.
-
-### Comportamento dos comandos
-
-O comando \`implemente\` considera o estado atual do trabalho:
-
-* sem alvo definido, abre uma Conversation de planejamento
-* em \`draft\`, conclui o plano
-* em \`ready\`, inicia a execução
-* em estados ativos ou com falha, continua, retoma ou inicia o rework
-
-Os comandos \`desenvolva\`, \`melhore\` e \`aprimore\` sempre retornam ao planejamento ou ao rework.
-
-Um PRD cancelado não pode ser alterado. Quando necessário, um novo PRD de rework é criado, preservando o vínculo e o histórico de auditoria.
-
-### Rastreamento de execução
-
-Toda criação de PRD ou SPEC é vinculada à Run responsável por meio do campo \`creation_run_id\`.
-
-Tempo, tokens e custo são agregados sempre que essas informações estiverem disponíveis ou forem reconciliadas. Quando não houver dados suficientes, os valores permanecem como \`unknown\` ou \`null\`.
-
-
-## Qualidade e evidências
-
-Qualidade faz parte da definição de pronto. Cada entrega combina testes, revisão e checks proporcionais ao seu risco, com comprovação objetiva dos Critérios de Aceite.
-
-As Evidence conectam o resultado observado à Task, à Change e à Execution que o produziram. Assim, é possível consultar o que foi validado, por qual método e em qual contexto, sem perder a linha de raciocínio da entrega.
-
-Tests, reviews, checks e Evidence tornam a evolução do projeto mais previsível: elevam a confiança nas mudanças, facilitam revisões e mantêm decisões, validações e aprimoramentos plenamente rastreáveis.
-
-
-## Economia medida e meta central por tarefa
-
-As análises abaixo apresentam reduções de custo **medidas na amostra comparativa** sob duas perspectivas complementares: custo médio por Task e custo médio por hora. Os gráficos e a tabela detalham os valores, os cálculos e a leitura de cada indicador. Os resultados confirmam redução nas séries analisadas, mas não devem ser generalizados para toda Task, modelo ou repositório sem uma nova comparação equivalente.
-
-### Análise de custo por tarefa
-
-Este gráfico acompanha o custo de cada Task nas duas faixas comparadas. A média inicial é de **R$ 67 por tarefa**; no recorte posterior, ela passa a **R$ 44**. A redução de **34,3%** (apresentada como aproximadamente 34%) representa o custo médio menor para concluir uma unidade de trabalho na amostra observada.
-
-<img src=".agents/config/src/analise_comparativa_reducao_custo_por_tarefa.png" alt="Análise comparativa: custo médio por tarefa caiu de R$ 67 para R$ 44" width="900">
-
-### Análise de custo por hora
-
-Este gráfico apresenta a mesma comparação na perspectiva horária. A média de custo cai de **R$ 410 por hora** para **R$ 154 por hora**, uma redução de **62,4%** (aproximadamente 62%). Essa leitura complementa a análise por Task ao mostrar que a redução também se mantém quando o custo é observado por hora.
-
-<img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Análise comparativa: custo médio por hora caiu de R$ 410 para R$ 154" width="900">
-
-Cada indicador abaixo mede uma parte diferente do fluxo. Os percentuais não devem ser somados, pois podem refletir otimizações simultâneas na mesma execução. As métricas de contexto e payload continuam sendo medições reproduzíveis do snapshot de **18/08/2026**; elas não descrevem automaticamente a população atual de skills ou do repositório.
-
-As duas primeiras linhas são resultados financeiros observados nas séries comparativas. As demais isolam ganhos de payload e navegação que ajudam a explicar como o fluxo pode reduzir custo, ciclos e retrabalho.
-
-| O que é reduzido | O que representa | Baseline sem a otimização | Com ZAIP-AIOS | Economia | Situação da métrica |
-| --- | --- | ---: | ---: | ---: | --- |
-| **Custo médio por tarefa** | Média de custo das Tasks nas duas faixas da série comparativa. | **R$ 67** | **R$ 44** | **34%** | **Medição observada** na comparação apresentada (redução exata: 34,3%). |
-| **Custo médio por hora** | Média de custo por hora nas duas faixas da série comparativa. | **R$ 410** | **R$ 154** | **62%** | **Medição observada** na comparação apresentada (redução exata: 62,4%). |
-| **Contexto entregue ao agente para uma Task** | O pack de Rules, Requirements e artefatos relevantes que entra no prompt de trabalho. | 7.980 tokens | **1.593 tokens** | **80,0%** | Medição reproduzível. |
-| **Navegação operacional recorrente** | Uma rodada de quatro consultas para localizar Changes, Tasks, Executions e Runs ativos. | 101.924 tokens | **10.199 tokens** | **90,0%** | Medição reproduzível; também reduz o limite de paginação. |
-| **Instruções disponíveis para o agente** | Snapshot de 13/07/2026 do catálogo então consultável pelo agente (26 skills). | 1.091 tokens | **599 tokens** | **45,1%** | Medição reproduzível do snapshot; não é a contagem atual de skills. |
-
-
-### Metodologia da comparação
-
-A comprovação de economia baseia-se em coortes de Tasks equivalentes, observadas em dois cenários — por exemplo, Codex normal e Codex + ZAIP-AIOS — com o mesmo modelo, repositório, Critérios de Aceite e janela de observação. Essa equivalência mantém a comparação centrada no efeito do fluxo de trabalho.
-
-Os indicadores que compõem a análise são:
-
-- tokens e custo equivalente de API de todas as chamadas até a conclusão;
-- duração e número de ciclos/retries;
-- tempo humano de revisão e correção;
-- taxa de rework e defeitos encontrados após a entrega;
-- cobertura de testes, reviews e evidências dos Critérios de Aceite.
-
-O Cost Monitor preserva valores desconhecidos como \`unknown\`/\`null\` e não converte ausência de telemetria em custo zero. Dessa forma, os resultados mantêm visíveis custos de provider, rework ou qualidade que ainda não tenham sido observados. A metodologia e seus registros complementares estão em [a auditoria de tokens e performance](analysis/verificacao-auditoria-tokens-performance-zaip-aios-2026-07-13.md).
-
-O comando \`zaip cost cohort --input <arquivo.json> --json\` calcula coortes comparáveis a partir de custos faturados observados e sua proveniência. O contrato de cálculo exige moeda USD, fonte, timestamp, *quality floor*, tentativa terminal e uma única identidade de baseline equivalente. Na ausência ou divergência de uma dimensão obrigatória, a economia permanece \`null\`, preservando a integridade da comparação.
-
-## Comparação com os principais frameworks concorrentes
-
-Este recorte usa uma auditoria comparativa, consolidada em 6 de agosto de 2026, e posiciona cada produto a partir dos sinais encontrados em código, configuração, arquitetura, testes e documentação. A metodologia reúne dez critérios com o mesmo peso: cada tópico recebe de 0 a 10 pontos e a nota final, de 0 a 100, é a soma direta desses resultados. Na escala adotada, 9–10 indica uma referência clara no critério; 7–8, uma proposta forte e competitiva; 5–6, uma capacidade relevante ainda parcial; e 0–4, pouca evidência ou baixa ênfase no recorte analisado. A matriz detalhada torna a composição das notas transparente e permite atualizá-las conforme os produtos evoluem.
-
-| Produto | Nota /100 | Justificativa da nota | Posicionamento competitivo |
-|---|---:|---|---|
-| ZAIP-AIOS | **95** | Lidera tecnicamente neste recorte local ao unir SDD, arquitetura limpa e qualidade baseada em Evidence com orquestração multiagente, segurança, contexto e observabilidade financeira por Task no mesmo lifecycle auditável. | Plataforma completa para engenharia de software com agentes, reunindo especificação, execução, validação, segurança e observabilidade em um lifecycle rastreável. |
-| Traycer | 83 | Coding agents conectados, loops agente–agente para arquitetura/review, CLI/terminal e worktrees são fortes; custo por Task e execução do host assinado não foram reproduzidos. | Mais especializado que OpenClaw para orquestrar coding agents, sem substituir validação de produto. |
-| AIOX Core | 82 | Spec pipeline, dev/QA, worktrees, recovery, memória e integrações Codex/Cursor/Claude sustentam o fluxo; hooks têm paridade desigual e não há custo por Task. | Plataforma de desenvolvimento ampla, com DX forte mas menos direta que Traycer. |
-| Kilo Code | 80 | Agente de código para VS Code, JetBrains e CLI, com Debug, Review, autocorreção e \`kilo run --auto\`; telemetria existe, mas custo por Task não foi comprovado. | DX de programação first-class, com limites de evidência em isolamento e recovery. |
-| TLC Spec-Driven | 80 | Skill SDD adaptativo com AC→teste, matriz de cobertura, verifier independente, sensor de discriminação e lessons locais; o contrato é forte, mas o enforcement depende de agente/host. | Muito forte em rastreabilidade e verificação; benchmark autorreferenciado sem bruto e sem telemetria/custo por Task. |
-| Roo Code | 79 | VS Code com modos Code, Architect e Debug, refactor, histórico/resume e worktrees; não há custo consolidado por Task. | Encaixe editor-first muito forte, com governança operacional parcial. |
-| Superpowers | 78 | Skills de TDD, worktrees, subagentes, review e debugging tornam o playbook de programação consistente; suas garantias continuam instrucionais e os testes comportamentais dependem de repositório externo. | Forte disciplina para coding agents, sem lifecycle tipado nem custo por Task. |
-| OpenClaw | 73 | Subagentes Codex-native, sessões isoladas, sandbox e testes são fortes, mas o gateway assistente multicanal não demonstra o mesmo fluxo coding-first de IDE/CLI. | Referência em isolamento e operação geral; fica abaixo de Traycer, Kilo e Roo no recorte de programação. |
-| Hermes | 71 | Retry, memória e usage/pricing sustentam recursos de coding, mas a plataforma é generalista e não coding-first; custo por Task não está demonstrado. | Produto autônomo amplo, não equivalente automaticamente a um agente de desenvolvimento especializado. |
-| OpenSpec | 70 | Delta specs, schemas, CLI, workspaces e testes estruturam a evolução de mudanças; a verificação é opcional/parcialmente heurística. | Especialista em gestão de specs, não runtime multiagente, sem custo por Task. |
-| OpenCode  | 60 | TUI/CLI, edição/patch, comandos, LSP, MCP/providers, permissões e sessões SQLite compõem uma base enxuta e extensível para programação no terminal. | Alternativa direta para desenvolvimento no terminal, com oportunidades de ampliar multiagentes, lifecycle, testes e custo por Task. |
-
-**Consultar a matriz técnica dos dez critérios**
-
-| Tópico (0–10) | ZAIP | OpenClaw | Traycer | Kilo | Hermes | AIOX | Roo Code | OpenCode | TLC Spec-Driven | Superpowers | OpenSpec |
-|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
-| T1 — SDD e rastreabilidade | 10 | 6 | 7 | 6 | 6 | 9 | 6 | 3 | 9 | 8 | 9 |
-| T2 — Loop planejar–editar–testar–corrigir | 9 | 7 | 9 | 10 | 7 | 9 | 9 | 8 | 9 | 9 | 6 |
-| T3 — Multiagentes e isolamento | 10 | 9 | 9 | 8 | 7 | 9 | 8 | 4 | 8 | 9 | 5 |
-| T4 — Arquitetura e repositório | 10 | 8 | 9 | 8 | 7 | 8 | 8 | 8 | 7 | 7 | 8 |
-| T5 — Testes, review e evidência | 10 | 9 | 9 | 9 | 8 | 9 | 9 | 5 | 9 | 9 | 8 |
-| T6 — Recovery e idempotência | 10 | 7 | 9 | 7 | 7 | 8 | 7 | 6 | 8 | 8 | 7 |
-| T7 — Supply chain | 9 | 8 | 8 | 8 | 8 | 7 | 8 | 6 | 7 | 7 | 6 |
-| T8 — Memória de codebase | 9 | 8 | 9 | 8 | 9 | 9 | 8 | 7 | 9 | 8 | 8 |
-| T9 — Telemetria/custo por tarefa de programação | 9 | 6 | 5 | 6 | 6 | 6 | 6 | 4 | 5 | 4 | 4 |
-| T10 — DX CLI/IDE, debug, review, setup e Codex-first | 9 | 5 | 9 | 10 | 6 | 8 | 10 | 9 | 9 | 9 | 9 |
-
-
-## Da conversa ao trabalho executável
-
-O framework ZAIP-AIOS transforma linguagem natural em engenharia estruturada. O usuário pode enviar uma mensagem curta, manter uma conversa de refinamento ou fornecer a transcrição de um áudio longo explicando contexto, restrições e resultado desejado. O framework avalia complexidade, dependências, amplitude e risco para propor a entrada adequada: uma Task para trabalho direto, uma SPEC para uma entrega técnica com múltiplas Tasks ou um PRD para uma iniciativa de produto composta por uma ou mais SPECs. A criticidade \`leve\`, \`padrão\` ou \`crítica\` determina a profundidade de planejamento, revisão, segurança e evidência exigida; nenhum artefato fica fechado à revisão humana.
-
-Isso permite sair de uma conversa livre sem cair em *vibe coding*: perguntas e análises read-only permanecem Conversations sem Task; pedidos de ação tornam-se trabalho executável. Antes da mutação, a intenção é convertida em requisitos, critérios de aceite, escopo, dependências e write scopes, e uma Task com Run raiz de orquestração entra em Execução. Consulte [Lifecycle de Conversations, Tasks, SPECs e PRDs](docs/WORK-LIFECYCLE.md).
-
-## Método ZAIP em seis etapas
-
-| Etapa | Artefatos | O que acontece |
-| --- | --- | --- |
-| **1. Definição** | PRD + Requirements | Registra objetivo, contexto, público, restrições, resultado esperado e Critérios de Aceite que definem o trabalho. |
-| **2. Planejamento** | SPEC + Changes | Descreve escopo, solução, arquitetura, riscos e mudanças previstas antes da execução, seguindo SDD. |
-| **3. Execução** | Tasks + DAG + Executions + Runs | Coordena Tasks, dependências, agentes e arquivos produzidos; registra cada tentativa e seu consumo observável. |
-| **4. Decisões** | Decisions (Human + AI / Planning + Execution) | Preserva decisões humanas e da IA tomadas durante planejamento, execução, revisão e reparo, com contexto e consequências. |
-| **5. Verificação** | Tests + Reviews + Evals + Checks | Executa os mecanismos de qualidade e compara o resultado observado com os requisitos e Critérios de Aceite. |
-| **6. Evidências** | Evidence + Results + Traceability | Coleta, registra e relaciona as provas produzidas pela verificação às Tasks, Changes, Runs e aos Critérios de Aceite; o trabalho só é concluído quando as evidências são suficientes e reproduzíveis. |
-
-O método mantém intenção e execução separadas. PRD e SPEC explicam o que se pretende entregar; Change, Task, Execution e Run registram como o trabalho foi realizado; Decisions explicam por que caminhos relevantes foram escolhidos; a Verificação executa testes, reviews, evals e checks; e Evidence preserva os resultados observados e sua relação com os Critérios de Aceite. Assim, “concluído” é um estado demonstrado por diff, resultado e evidência reproduzível, não apenas declarado por um agente.
-
-## Cadeia completa de execução
-
-Os conceitos abaixo formam o vocabulário técnico usado para ligar intenção, planejamento, execução e prova sem perder o histórico.
-
-**Consultar o glossário completo do lifecycle**
-
-| Conceito | Responsabilidade |
-| --- | --- |
-| **Rule** | Regra durável de comportamento, arquitetura, segurança, contexto ou qualidade que o Codex deve seguir. |
-| **Requirement** | Obrigação verificável do produto, acompanhada de Critérios de Aceite. |
-| **PRD** | Documento de Requisitos do Produto que governa uma iniciativa e organiza uma ou mais SPECs. |
-| **SPEC** | Especificação técnica SDD que detalha solução, escopo, riscos, Changes, Tasks e DAG. |
-| **Change** | Narrativa viva de uma mudança planejada e executada: decisões, arquivos afetados, desvios, testes, evidências, rollout, rollback e resultado. |
-| **Task** | Menor unidade executável, com objetivo, risco, prioridade, dependências, write scopes e critérios de aceite. |
-| **DAG** | Grafo acíclico que ordena dependências, identifica paralelismo seguro e impede execução fora da sequência necessária. |
-| **Execution** | Uma unidade idempotente por turno: \`interaction\` registra conversa sem Task artificial; \`delivery\` materializa e coordena trabalho, Changes e DAG quando aplicável. |
-| **Run / Sub-Run** | Run de captura ou do agente orquestrador possui \`parent_run_id: null\`; Sub-Run é cada chamada de subagente relacionada por \`parent_run_id\`. Novos registros usam \`run_role: intake|orchestrator|subagent\`; cada chamada fixa modelo e effort e agrega suas Calls internas. |
-| **Decision** | Decisão humana ou da IA com contexto, alternativa escolhida, motivo, consequências e possibilidade de rollback. |
-| **Evidence** | Prova associada à Task e aos Critérios de Aceite: teste, diff, review, check, relatório ou resultado reproduzível. |
-| **Eval** | Avaliação determinística ou orientada por rubrica que mede qualidade, regressão, aderência e performance. |
-
-
-## Três formas de executar
-
-1. **Task-first:** executa uma única Task independente para mudanças diretas e bem delimitadas.
-2. **SPEC:** executa um conjunto de Tasks relacionadas, coordenadas por uma DAG e governadas pela mesma especificação técnica.
-3. **PRD:** executa uma iniciativa completa, selecionando uma ou mais SPECs, cada uma com suas Changes, Tasks e dependências.
-
-Essa progressão permite começar de forma simples e acrescentar planejamento apenas quando a amplitude, as dependências ou o risco justificarem uma estrutura maior.
-
-**Políticas técnicas de execução e assurance**
-
-Conversation e Task-first preservam o modelo, o reasoning effort e a velocidade selecionados manualmente no Codex. Para executar trabalho de produto mais rápido, o único caminho suportado é uma Task-first realmente independente com Fast selecionado manualmente no Codex. Executions originadas por SPEC ou PRD usam sempre velocidade \`standard\`, inclusive em todas as Tasks descendentes; o ZAIP não oferece skill, hook ou override para mudar essa velocidade.
-
-Em todos os casos, cada turno observável resolve para uma Execution. \`prepare\` valida e congela o plano antes da mutação; \`execute\` reutiliza a Execution \`delivery\` para materializar Change e Task; cada Execution usa uma Run raiz do orquestrador, ao menos um Sub-Run executor elegível e o \`zaip-agent-finalizer\` obrigatório por último. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.
-
-A profundidade de prova é adaptativa: Task standalone \`lite\` exige no mínimo uma validação tipada e uma Evidence, normalmente uma de cada, mas aceita provas adicionais legítimas. \`standard\` exige duas ou três validações conforme \`verification_scope\` e pelo menos uma Evidence consolidada; \`critical\` exige três ou mais, revisão independente e os sinais de risco persistidos que determinam controles adicionais. Entregas de SPEC e PRD acrescentam matriz parental, pelo menos três validações e três Evidences, integração real e revisão independente. O runtime manual continua padrão; a autonomia por Codex ou Claude é opt-in, isolada em worktrees e limitada por write scopes, commits, budgets e gates tipados. Consulte [Assurance adaptativa e autonomia opt-in](docs/ASSURANCE-E-AUTONOMIA.md).
-
-
-## Princípios de engenharia autônoma
-
-O ZAIP-AIOS combina velocidade com limites explícitos. Seus princípios mantêm o código sustentável, distribuem apenas o contexto necessário e exigem comprovação proporcional ao risco.
-
-- **Clean Architecture:** domínio, aplicação, adapters e infraestrutura permanecem separados; regras de negócio não dependem de frameworks ou detalhes externos, as dependências apontam para as camadas internas e composition roots conectam implementações concretas nas bordas.
-- **CQRS:** commands e queries seguem fluxos explícitos e independentes; comandos alteram estado por casos de uso e ports apropriados, enquanto consultas não produzem efeitos colaterais e retornam read models adequados à leitura.
-- **Modularização e organização do código:** pastas, arquivos, módulos e componentes são estruturados por domínio e responsabilidade, com fronteiras explícitas, alta coesão e baixo acoplamento para facilitar navegação, manutenção, testes e evolução do software.
-- **Autonomia dentro de limites:** subagentes trabalham com DAG, write scopes, sandbox, approvals, budgets, regras de segurança e gates proporcionais ao risco.
-- **Contexto progressivo:** cada agente recebe apenas Rules, Requirements, skills e evidências relevantes para seu papel, reduzindo ruído, custo e perda de contexto.
-- **Conclusão baseada em prova:** testes, review, evals, checks e Evidence precisam cobrir os Critérios de Aceite antes da entrega.
-- **Histórico recuperável:** decisões, mudanças, tentativas, falhas, retries, reparos e rollback permanecem vinculados, permitindo pausar, retomar e auditar o trabalho.
-- **Observabilidade honesta:** tokens, custo, tempo, cobertura e performance são medidos por escopo; ausência de telemetria permanece explícita em vez de gerar precisão fictícia.
-
-Toda mensagem do usuário cria uma Execution e uma Run de captura. Perguntas, feedbacks e análises read-only usam Execution \`interaction\`, sem Task ou Change artificial. A criação ou o refinamento explícito de PRD/SPEC \`draft\` é a exceção de definição: a própria \`interaction\` pode persistir esses macros e o PreparedPlan sem Task, Change ou Execution \`delivery\`. Fora dessa exceção, pedido avulso direto materializa e inicia a mesma Execution \`delivery\`, Task, Change e Run raiz de orquestração antes da primeira mutação; somente preparação explicitamente solicitada pode parar em Pronto para Executar. PRD \`draft\` ocupa Definição e SPEC \`draft\` ocupa Planejamento; Tasks nunca ocupam essas colunas.
-
-## Graph Engineering e Loop Engineering
-
-<img src=".agents/config/src/zaip-aios-obsidian.png" alt="Zaip AIOS no Obsidian" width="100%">
-
-O **Graph Engineering** transforma uma entrega complexa em uma sequência coordenada de responsabilidades. Em vez de acionar todos os 23 agentes, a orquestração escolhe o menor conjunto capaz de planejar, executar, revisar e comprovar o resultado conforme dependências, risco e especialidade.
-
-Essa autonomia permanece governada: Dave coordena, cada executor recebe apenas o escopo necessário, Nanda realiza a revisão independente, especialistas adicionais entram quando existem sinais objetivos e Gui encerra o fluxo por último. O resultado é uma equipe ajustada à demanda, sem multiplicar agentes e custo sem necessidade.
-
-O **Loop Engineering** orienta o que acontece quando a primeira tentativa não satisfaz os critérios de qualidade. A falha ou o bloqueio é classificado, o próximo ciclo recebe uma configuração proporcional à dificuldade observada e cada tentativa permanece auditável. Em execuções originadas de PRD ou SPEC, o sistema pode evoluir de **Luna → Terra → Sol** e de **low → medium → high → xhigh**; Conversations e Tasks avulsas preservam a seleção manual do host/Codex. O modelo nunca muda silenciosamente dentro da mesma Run.
-
-### Grafo principal
-
-Este é o caminho mais comum e econômico. Todos os agentes são filhos diretos da mesma orquestração de Dave; a sequência lógica não significa que um trabalhador chama o próximo.
-
-\`\`\`mermaid
-flowchart LR
-    I["Entrada"] --> C["Classificar demanda"]
-    C --> D["Dave<br/>orquestrador"]
-    D --> E{"Executor por capacidade"}
-    E -->|Task genérica| L["Leo"]
-    E -->|Trabalho técnico amplo| R["Rafa"]
-    E -->|Domínio específico| S["Especialista"]
-    L --> D
-    R --> D
-    S --> D
-    D --> N["Nanda<br/>review independente"]
-    N -->|Aprovado| D
-    N -->|Rework| D
-    D --> G["Gui<br/>finalizador"]
-    G --> O["Resultado terminal"]
-\`\`\`
-
-\`\`\`text
-Dave → um executor ou especialista → Nanda → Gui
-\`\`\`
-
-### Loop de custo e qualidade
-
-O diagrama abaixo representa a política automática para execuções originadas de PRD/SPEC com \`model_orchestration.mode:auto\`. Em Conversation e Task-first, o host/Codex mantém a seleção manual de modelo e effort.
-
-\`\`\`mermaid
-flowchart LR
-    A["Tentativa"] --> V{"Gates e review passaram?"}
-    V -->|Sim| F["Finalizar"]
-    V -->|Não| R["Classificar rework"]
-    R --> C["Recalibrar agente, modelo e esforço"]
-    C -->|Simples e delimitado| L["Luna / low"]
-    C -->|Execução padrão| T["Terra / medium"]
-    C -->|Ambíguo, transversal ou rework estrutural| S["Sol / high ou xhigh"]
-    L --> A
-    T --> A
-    S --> A
-\`\`\`
-
-O escalonamento não é obrigatório em toda falha. Um erro determinístico pode continuar barato; a classificação \`critical\` amplia os guards de assurance, mas não eleva mecanicamente o executor. Sol e \`xhigh\` são reservados para ambiguidade, transversalidade, review/audit, rework estrutural ou dificuldade observável.
-
-**Formas de entrada**
-
-\`\`\`mermaid
-flowchart TD
-    U["Solicitação"] --> T{"Tipo de entrada"}
-    T -->|Pergunta simples| Q["Resposta direta"]
-    T -->|Análise especializada| A["Interaction"]
-    T -->|Mudança delimitada| K["Task-first"]
-    T -->|Problema de produto| P["PRD"]
-    T -->|Definição técnica| S["SPEC"]
-    T -->|Continuação| C["Retomar foco"]
-    T -->|Falha ou achado| W["Rework"]
-    T -->|Auditoria| X["Audit"]
-    T -->|Deploy ou push| Git["Git-only"]
-    A --> D["Dave"]
-    K --> D
-    P --> B["Bia"]
-    S --> R["Rafa"]
-    C --> D
-    W --> D
-    X --> D
-    B --> D
-    R --> D
-\`\`\`
-
-
-**Planejamento com PRD e SPEC**
-
-\`\`\`mermaid
-flowchart LR
-    I["Ideia ou problema"] --> D["Dave"]
-    D --> B["Bia<br/>PRD e critérios"]
-    B --> D
-    D --> R["Rafa<br/>SPEC e DAG técnica"]
-    R --> D
-    D --> V{"Pronto para executar?"}
-    V -->|Refinar produto| B
-    V -->|Refinar técnica| R
-    V -->|Sim| X["Materializar Tasks"]
-    X --> E["Executar DAG"]
-    E --> N["Nanda"]
-    N --> G["Gui"]
-\`\`\`
-
-
-**Demanda crítica e transversal**
-
-\`\`\`mermaid
-flowchart TD
-    I["Demanda crítica"] --> D["Dave<br/>orquestração"]
-    D --> P["Bia ou Rafa<br/>planejamento"]
-    P --> D
-
-    D --> B1["Will<br/>backend"]
-    D --> B2["Doug<br/>frontend"]
-    D --> B3["Manu<br/>design"]
-    D --> B4["Dan<br/>cloud"]
-
-    B1 --> D
-    B2 --> D
-    B3 --> D
-    B4 --> D
-
-    D --> DI["Dani<br/>integração quando necessária"]
-    DI --> D
-    D --> N["Nanda<br/>review obrigatório"]
-    N --> D
-
-    D --> SEC{"Há segurança ou dados críticos?"}
-    SEC -->|Sim| L["Luiz<br/>security audit"]
-    SEC -->|Não| CRIT{"Há release, alto risco ou auditoria ampla?"}
-    L --> D
-    D --> CRIT
-    CRIT -->|Sim| A["Ana<br/>auditoria independente"]
-    CRIT -->|Não| G["Gui"]
-    A --> D
-    D --> G["Gui<br/>último agente"]
-\`\`\`
-
-Nanda cobre a revisão independente normal. Luiz é adicional quando há segurança ou dados críticos. Ana é adicional para alto risco, release ou reprodução ampla de evidências. Uma demanda pode usar Nanda, Luiz e Ana quando todos os guards forem verdadeiros.
-
-
-**Seleção de modelo e esforço**
-
-\`\`\`mermaid
-flowchart TD
-    A["Agente selecionado"] --> F["Identificar papel e fase"]
-    F --> S["Ler sinais persistidos"]
-    S --> R["Classificar criticidade"]
-    R --> O{"Override explícito válido?"}
-    O -->|Execution| OE["Override da Execution"]
-    O -->|Task| OT["Override da Task"]
-    O -->|Não| P["Política automática"]
-    P --> X{"Perfil da Agent Run"}
-    X -->|Simples, local e verificável| L["Luna / low"]
-    X -->|Execução standard| T["Terra / medium"]
-    X -->|Crítico e tecnicamente claro| TH["Terra / medium + assurance"]
-    X -->|Planejamento ou ambiguidade alta| SH["Sol / medium ou high"]
-    X -->|Múltiplos gatilhos excepcionais| SX["Sol / xhigh"]
-    OE --> V["Validar capacidades do host"]
-    OT --> V
-    L --> V
-    T --> V
-    TH --> V
-    SH --> V
-    SX --> V
-    V --> RUN["Abrir Agent Run imutável"]
-\`\`\`
-
-\`\`\`text
-Modelo = papel + fase + complexidade + ambiguidade + transversalidade
-Esforço = criticidade + dificuldade de raciocínio + custo do erro
-Assurance = criticidade + impacto + rollback
-\`\`\`
-
-
-**Matriz recomendada por agente**
-
-| Agente | Lite | Standard | Crítico |
-|---|---|---|---|
-| Dave | Terra/medium | Terra/medium | Sol/medium ou high somente em planejamento, ambiguidade ou transversalidade |
-| Rafa | Luna/low quando simples e delimitado | Terra/medium | Terra/medium; risco critical amplia assurance, não o modelo mecanicamente |
-| Leo | Luna/low quando simples e delimitado | Terra/medium | Terra/medium; Sol/high apenas por ambiguidade, transversalidade ou rework estrutural |
-| Bia | Terra/medium | Sol/medium | Sol/high quando o trabalho analítico for complexo ou ambíguo |
-| Gui | Terra/medium | Terra/medium | Terra/medium; o finalizer avalia Evidence já produzida e não escala automaticamente |
-| Nanda | Sol/medium | Sol/medium | Sol/high quando a revisão for complexa |
-| Dani | Terra/medium | Terra/medium | Terra/medium; integração não escala automaticamente |
-| Ana | Não acionar | Somente excepcional | Sol/high ou xhigh |
-| Lia | Luna/low | Luna/medium ou Terra/medium | Terra/high |
-| Gabi | Luna/low para cálculo mecânico | Terra/medium | Sol/high para diagnóstico causal complexo |
-| Tati | Terra/low | Terra/medium | Sol/high ou xhigh estrutural |
-| Doug | Luna/low | Terra/medium | Sol/high somente se transversal |
-| Will | Luna/low | Terra/medium | Sol/high para arquitetura ou risco material |
-| Jonny | Luna/low | Terra/medium | Sol/high para SEO, GEO ou arquitetura complexos |
-| Manu | Luna/low para aplicação de tokens | Terra/medium | Sol/high para mudança visual central |
-| Dan | Luna/low para configuração local | Terra/medium | Sol/high para infraestrutura crítica |
-| Luiz | Não acionar | Sol/medium quando necessário | Sol/high ou xhigh |
-| Lucia | Luna/low para variações | Terra/medium | Sol/high para estratégia ambígua |
-| Sarah | Luna/low para organização de fontes | Terra/medium | Sol/high para posicionamento ou arquitetura de marca ambíguos |
-| Robert | Luna/low para síntese delimitada | Terra/medium | Sol/high para diagnóstico estratégico, RevOps ou decisão financeira complexa |
-| Aaron | Luna/low para organizar roteiro delimitado | Terra/medium | Sol/high para processo comercial ambíguo ou negociação complexa |
-| Clara | Luna/low para artefato simples | Terra/medium | Sol/high para análise operacional ambígua ou transversal |
-| Renata | Luna/low para organização documental | Terra/medium | Sol/high para governança, privacidade ou risco complexo |
-
-
-**Perfis por criticidade**
-
-| Perfil | Orquestração | Execução | Review | Assurance adicional | Finalização |
-|---|---|---|---|---|---|
-| Lite | Dave, Terra/low | Luna/low | Nanda, Terra/low | Não | Gui, Terra/low |
-| Standard | Dave, Terra/medium | Terra/medium | Nanda, Terra/medium | Dani, Luiz ou Ana somente por guard | Gui, Terra/medium |
-| Critical | Dave, Terra/medium; Sol somente se planejamento, ambiguidade ou transversalidade exigirem | Terra/medium para execução tecnicamente clara; Sol/high por ambiguidade, transversalidade ou rework estrutural | Nanda, Sol/high quando a revisão for complexa | Dani, Terra/medium, por integração; Luiz ou Ana, Sol/high, pelos guards aplicáveis | Gui, Terra/medium |
-
-
-**Consultar o grafo unificado dos 23 agentes**
-
-### Grafo unificado dos 23 agentes
-
-\`\`\`mermaid
-flowchart TD
-    IN["Conversa, Task, SPEC, PRD, Rework ou Audit"] --> CL["Classificar intenção, capacidade e risco"]
-    CL -->|Sem delegação necessária| OUT["Resposta direta"]
-    CL --> D0["Dave<br/>seleciona a execução"]
-
-    D0 --> MC["Calibrar modelo e esforço da Agent Run"]
-    MC --> ROUTE{"Capacidade requerida"}
-
-    ROUTE --> BIA["Bia<br/>produto e PRD"]
-    ROUTE --> RAFA["Rafa<br/>SPEC e técnica ampla"]
-    ROUTE --> LEO["Leo<br/>Task genérica"]
-    ROUTE --> LIA["Lia<br/>documentação"]
-    ROUTE --> GABI["Gabi<br/>dados e métricas"]
-    ROUTE --> TATI["Tati<br/>refatoração"]
-    ROUTE --> DOUG["Doug<br/>frontend"]
-    ROUTE --> WILL["Will<br/>backend"]
-    ROUTE --> JONNY["Jonny<br/>website"]
-    ROUTE --> MANU["Manu<br/>design system"]
-    ROUTE --> DAN["Dan<br/>cloud"]
-    ROUTE --> LUCIA["Lucia<br/>marketing"]
-    ROUTE --> SARAH["Sarah<br/>branding"]
-    ROUTE --> ROBERT["Robert<br/>growth e RevOps"]
-    ROUTE --> AARON["Aaron<br/>vendas"]
-    ROUTE --> CLARA["Clara<br/>operações gerais"]
-    ROUTE --> RENATA["Renata<br/>governança e compliance"]
-
-    BIA --> D1["Dave<br/>recebe resultados"]
-    RAFA --> D1
-    LEO --> D1
-    LIA --> D1
-    GABI --> D1
-    TATI --> D1
-    DOUG --> D1
-    WILL --> D1
-    JONNY --> D1
-    MANU --> D1
-    DAN --> D1
-    LUCIA --> D1
-    SARAH --> D1
-    ROBERT --> D1
-    AARON --> D1
-    CLARA --> D1
-    RENATA --> D1
-
-    D1 --> INT{"Há branches para integrar?"}
-    INT -->|Sim| DANI["Dani<br/>integração"]
-    DANI --> D2["Dave<br/>recebe candidato integrado"]
-    INT -->|Não| D2
-
-    D2 --> REVIEW["Nanda<br/>review independente obrigatório"]
-    REVIEW -->|Rework| RW["Dave<br/>classifica rework e abre nova Agent Run"]
-    RW --> MC
-    REVIEW -->|Aprovado| SEC{"Segurança ou dados críticos?"}
-
-    SEC -->|Sim| LUIZ["Luiz<br/>security audit"]
-    LUIZ --> D3["Dave<br/>recebe avaliação de segurança"]
-    SEC -->|Não| D3
-    D3 --> AUDIT{"Alto risco, release ou auditoria ampla?"}
-
-    AUDIT -->|Sim| ANA["Ana<br/>auditoria independente"]
-    ANA --> D4["Dave<br/>recebe auditoria terminal"]
-    AUDIT -->|Não| D4
-    D4 --> GUI["Gui<br/>finalizador obrigatório e último"]
-
-    GUI --> TERM["Completed, blocked,<br/>failed ou cancelled"]
-\`\`\`
-
-O grafo comum usa quatro agentes. Os demais entram por guards de capacidade, dependência ou risco; o objetivo não é usar todos os 20 em toda demanda. O [guia completo de Graph Engineering dos agentes](guide/GRAPH-ENGINEERING-AGENTES-ZAIP.md) descreve os contratos dos nós, os cenários detalhados e as regras de escalada.
-
-
-## Fluxos
-
-Os fluxos abaixo documentam estados, transições, responsabilidades e critérios de encerramento para quem precisa operar ou auditar o lifecycle em profundidade.
-
-**Consultar fluxos, estados e regras práticas de operação**
-
-### Seis etapas principais e três saídas alternativas
-
-O lifecycle possui seis etapas no caminho de sucesso. \`Bloqueado\`, \`Falhado\` e \`Cancelado\` são saídas alternativas: elas podem interromper o fluxo, mas não são etapas pelas quais todo trabalho precisa passar.
-
-| Etapa | O que acontece | Estados Git-native mais comuns |
-| --- | --- | --- |
-| **1. Definição** | Registra problema, objetivo, escopo e Critérios de Aceite no PRD, que ainda pode ser refinado sem iniciar implementação. | PRD \`draft\` |
-| **2. Planejamento** | A SPEC \`draft\` detalha o trabalho, suas dependências, Changes previstos, DAG e estratégia de verificação. Uma Task não percorre esta etapa. | SPEC \`draft\`; PreparedPlan em construção |
-| **3. Pronto para Executar** | O plano foi validado, materializado e está apto a iniciar. Uma Task preparada entra no lifecycle por esta etapa. | PRD/SPEC \`ready\`; Task/Change \`planned\`; Execution \`planned\` |
-| **4. Execução** | Cada Task recebe sua própria orquestração, agentes elegíveis e ciclos de implementação ou correção. | PRD/SPEC \`active\`; Task/Change \`executing\`; Execution/Run \`running\` |
-| **5. Verificação** | Tests, reviews, evals, checks, Decisions e Evidence comprovam os Critérios de Aceite. SPEC e PRD fazem também sua verificação parental. | Change/Execution \`verifying\` |
-| **6. Concluído** | O resultado foi verificado e o nível correspondente foi encerrado. | Task/Change/Execution \`completed\`; PRD/SPEC \`delivered\` |
-| **Bloqueado** | Existe uma dependência ou impedimento recuperável. O trabalho pode continuar depois com \`resume\` ou \`rework\`. | \`blocked\` |
-| **Falhado** | Um impedimento técnico ou externo impede continuar com segurança após os retries permitidos, por exemplo, permissão negada, Codex/provider indisponível, falha de internet/rede ou erro em uma ferramenta obrigatória. | \`failed\` |
-| **Cancelado** | Uma pessoa encerra pontualmente o trabalho por decisão explícita; nunca é uma saída automática do agente. | \`cancelled\` |
-
-### Visão macro: cada tipo mantém seu próprio fluxo
-
-Task, SPEC e PRD não se misturam em uma única linha de execução. Uma SPEC coordena suas Tasks; um PRD coordena suas SPECs; e cada Task continua sendo executada e verificada de forma independente.
-
-Os três fluxos aparecem lado a lado em uma única imagem PNG, preservando a leitura no preview e deixando explícito que SPEC e PRD coordenam entregas sem fundir o lifecycle de cada Task.
-
-Uma Task não passa pelas etapas 1 e 2: quando preparada, ela começa em **3. Pronto para Executar**; quando direta, começa em **4. Execução**.
-
-![Lifecycles de Task, SPEC e PRD](docs/assets/diagrams/lifecycles-task-spec-prd.png)
-
-Conversation permanece fora dessas três linhas: ela usa uma Execution \`interaction\`, pode consultar agentes e termina em uma resposta sem criar Task artificial.
-
-### Orquestração de uma Task
-
-A Task é a unidade de execução do ZAIP. Para concluí-la, o sistema pode executar mais de um ciclo de orquestração, mas cada ciclo tem uma Run raiz, agentes com responsabilidades bem definidas, limites de tentativa e um resultado explícito. Isso evita que uma sequência longa de chamadas pareça uma única execução sem começo, fim ou responsável.
-
-O \`Zaip Agent Orchestrator\` conduz o ciclo e delega a implementação ou a correção ao \`Zaip Agent Executor\`. Enquanto o trabalho acontece, Evidence e Decisions registram o que foi feito, como foi validado e quais escolhas foram tomadas. Em seguida, o \`Zaip Agent Reviewer\` assume a verificação independente dos Critérios de Aceite, executando ou coordenando Tests, Checks e Evals. Quando a profundidade de prova exigir, o \`Zaip Agent Auditor\` acrescenta uma revisão adicional. Só então o \`Zaip Agent Finalizer\` recebe o resultado já verificado, consolida as evidências e fecha a Run raiz como o último Sub-Run: depois desse ponto, nenhuma nova chamada pode ser anexada ao ciclo.
-\`\`\`mermaid
-flowchart TD
-    TASK["Task em Execução"] --> ORCH["Zaip Agent Orchestrator<br/>Run raiz do ciclo N"]
-    ORCH --> EXECUTOR["Zaip Agent Executor<br/>implementação ou correção"]
-    EXECUTOR --> EVIDENCE["Coleta contínua durante a execução<br/>Evidence + Decisions registradas"]
-    EVIDENCE --> REVIEWER["Zaip Agent Reviewer<br/>executa e coordena a verificação"]
-    REVIEWER --> QUALITY["Camadas de validação<br/>Tests + Checks + Evals"]
-    QUALITY -->|validação suficiente| VERIFIED["Resultado verificado<br/>antes do fechamento"]
-    QUALITY -->|auditoria necessária| AUDITOR["Zaip Agent Auditor<br/>verificação adicional"]
-    AUDITOR --> VERIFIED
-    VERIFIED --> FINALIZER["Zaip Agent Finalizer<br/>consolida e encerra o ciclo"]
-    FINALIZER --> OUTCOME{"Resultado já verificado"}
-
-    OUTCOME -->|impedimento técnico, externo ou retries esgotados| FAILED["Falhado<br/>permissão, Codex/provider, internet/rede<br/>ou ferramenta impedem continuar"]
-    OUTCOME -->|critérios atendidos| DONE["Concluído"]
-    OUTCOME -->|condição recuperável| BLOCKED["Bloqueado<br/>aguarda condição"]
-    OUTCOME -->|correção necessária| REWORK["Rework necessário<br/>novo ciclo N + 1"]
-    OUTCOME -.-> HUMAN["Ação humana pontual<br/>solicitação de pausa"]
-    HUMAN --> CANCELLED["Cancelado"]
-
-    BLOCKED -->|resume dentro da política| ORCH
-    REWORK -->|novo ciclo dentro da política| ORCH
-
-    classDef entry fill:#2563eb,color:#fff,stroke:#1d4ed8,stroke-width:2px;
-    classDef agent fill:#6d28d9,color:#fff,stroke:#a78bfa;
-    classDef executor fill:#1e3a8a,color:#fff,stroke:#60a5fa,stroke-width:2px;
-    classDef reviewer fill:#c2410c,color:#fff,stroke:#fb923c,stroke-width:2px;
-    classDef auditor fill:#166534,color:#fff,stroke:#4ade80,stroke-width:2px;
-    classDef finalizer fill:#991b1b,color:#fff,stroke:#ef4444,stroke-width:2px;
-    classDef info fill:#334155,color:#fff,stroke:#94a3b8;
-    classDef success fill:#15803d,color:#fff,stroke:#4ade80,stroke-width:2px;
-    classDef warning fill:#a16207,color:#fff,stroke:#facc15;
-    classDef failure fill:#b91c1c,color:#fff,stroke:#f87171;
-
-    class TASK entry;
-    class ORCH agent;
-    class EXECUTOR executor;
-    class REVIEWER reviewer;
-    class AUDITOR auditor;
-    class FINALIZER finalizer;
-    class EVIDENCE,QUALITY,VERIFIED,OUTCOME,HUMAN info;
-    class DONE success;
-    class BLOCKED,REWORK,CANCELLED warning;
-    class FAILED failure;
-\`\`\`
-O encerramento nunca decide sozinho se o trabalho está pronto: essa decisão já foi sustentada pelo Reviewer, pelas camadas de validação e, quando necessário, pelo Auditor. A partir daí, o fluxo separa claramente o resultado funcional da Task do status técnico da Run.
-
-- **Concluído:** os Critérios de Aceite foram comprovados e a entrega está pronta.
-- **Bloqueado:** há uma condição recuperável; o ciclo pode ser retomado dentro da política configurada.
-- **Rework necessário:** a validação encontrou uma correção necessária; um novo ciclo é iniciado com o contexto e as evidências anteriores.
-- **Falhado:** um impedimento técnico ou externo, como permissão insuficiente, indisponibilidade do Codex ou provider, falha de rede ou ferramenta, ou tentativas esgotadas, impede continuar com segurança.
-- **Cancelado:** uma pessoa solicitou explicitamente a interrupção; não é uma decisão automática do fluxo.
-
-Bloqueio e rework não descartam o que já foi produzido. Eles retornam ao Orchestrator para um novo ciclo controlado, respeitando os limites de retries, orçamento e política da Execution.
-
-### Regras práticas de operação
-
-#### Entrada e preparação
-
-- **Conversation:** usa uma Execution \`interaction\` e termina em resposta, sem criar Task artificial.
-- **Task direta:** a captura cria Task, Change e Execution e inicia a execução imediatamente.
-- **Task preparada:** permanece em Pronto para Executar até o comando \`execute\`.
-- **SPEC:** coordena a DAG de suas Tasks, mas cada Task mantém execução, Run e evidências próprias.
-- **PRD:** coordena as SPECs selecionadas no PreparedPlan, sem fundir os seus lifecycles.
-
-Task direta e Task preparada seguem a mesma trilha controlada, mas refinamentos e reworks podem criar novos ciclos de orquestração. Cada novo ciclo começa explicitamente por \`execute\`, \`resume\` ou \`rework\` e respeita os limites de retries e reparos da Execution.
-
-O prepare automático atende somente uma Task sem dependências. Uma DAG manual requer um plano construído e validado antes da preparação da Task:
-
-\`\`\`bash
-zaip plan build --draft DRAFT.json --output PLAN.json
-zaip plan validate --plan PLAN.json
-zaip task prepare TASK-ID --plan PLAN.json
-\`\`\`
-
-Um PRD precisa ter pelo menos uma SPEC para chegar a \`ready\`, \`active\` ou \`delivered\`. A entrega considera apenas as SPECs selecionadas no seu PreparedPlan; SPECs fora desse plano não são encerradas implicitamente.
-
-#### Refinamento Git-native
-
-Enquanto PRD ou SPEC estiverem em \`draft\`, o refinamento ocorre diretamente no Markdown versionado e incrementa \`revision\` e \`updated_at\`. Depois de \`prepare\`, o plano materializado não é alterado silenciosamente: uma mudança semântica exige a transição explícita suportada de volta para draft ou a criação de um novo draft.
-
-#### Verificação e encerramento
-
-Os Sub-Runs executores produzem a implementação enquanto Evidence e Decisions registram continuamente provas e escolhas relevantes. Em seguida, o \`Zaip Agent Reviewer\` executa ou coordena Tests, Checks e Evals para verificar os Critérios de Aceite; o \`Zaip Agent Auditor\` pode acrescentar uma checagem independente. Somente depois dessas etapas o \`Zaip Agent Finalizer\`, papel canônico \`zaip-agent-finalizer\`, consolida o resultado já verificado e encerra a sequência de Sub-Runs como barreira final do ciclo.
-
-Depois do Finalizer, encerre a Run raiz mantendo separados o status técnico da Run e o resultado funcional da Task:
-
-\`\`\`bash
-zaip run finish RUN-ID \\
-  --status completed \\
-  --task-outcome completed
-zaip run closure RUN-ID
-\`\`\`
-
-Substitua \`completed\` em \`--task-outcome\` por \`blocked\`, \`failed\` ou \`cancelled\` quando esse for o resultado funcional verificado da Task.
-
-Gates estruturais disponíveis incluem:
-
-\`\`\`bash
-zaip architecture validate
-zaip modules validate
-zaip profile validate
-zaip cqrs validate # quando aplicável
-\`\`\`
-
-\`zaip run reconcile --open\` é um reparo global manual. No dashboard, ele só é executado depois de confirmação explícita no popup.
-
-#### Observabilidade e projeções
-
-\`zaip run list\` disponibiliza a navegação pelas Runs, e \`zaip run aggregate\` agrega tokens e custos no escopo informado. O dashboard, o Kanban e o Cost Monitor são projeções do estado Git-native; eles não substituem os records canônicos.
-
-Conversation, Planning e Execution permanecem separados. Tokens, custos, tempo, performance e rework podem ser analisados por Task, SPEC e PRD. Valores indisponíveis continuam como \`unknown\` ou \`null\`: totais, estimativas e cobertura nunca transformam ausência de telemetria em zero.
-
-
-## Referência técnica e operacional
-
-As seções seguintes preservam os contratos necessários para instalação avançada, manutenção, auditoria, segurança e evolução do framework. Elas complementam a visão comercial sem substituir os guias especializados vinculados ao longo do documento.
-
-## Estrutura atual de \`.agents\`
-
-**Consultar a árvore de diretórios e as responsabilidades técnicas**
-
-\`\`\`text
-.agents/
-├── config/
-│   ├── project.yaml
-│   ├── framework.lock.yaml
-│   ├── agents/catalog.yaml
-│   └── profiles/clients.yaml
-├── dashboard/
-│   ├── zaip-dashboard-windows.exe
-│   ├── zaip-dashboard-linux.sh
-│   ├── zaip-dashboard-mac.command
-│   ├── apps/frontend/
-│   ├── modules/{operations,cost-monitor,traceability}/
-│   ├── packages/
-│   └── tests/e2e/
-├── design/
-│   ├── DESIGN.md
-│   ├── tokens.json
-│   ├── zaip-design.exe
-│   ├── apps/catalog/
-│   └── packages/
-├── records/
-│   ├── prds/<ano>/<mês>/
-│   ├── specs/<ano>/<mês>/
-│   ├── changes/<ano>/<mês>/
-│   ├── tasks/<ano>/<mês>/
-│   ├── executions/<ano>/<mês>/
-│   ├── runs/<ano>/<mês>/
-│   ├── lifecycle/{manifest.json,summary.json,entity-snapshot.json}/
-│   └── telemetry/<ano>/<mês>/writers/<writer-id>/{manifest.json,chunks/}
-├── rules/
-│   ├── zaip/{core,workflow,architecture,security,context,evolution}.md
-│   └── project/            # Rules personalizadas deste projeto
-├── requirements/
-├── skills/
-├── tools/
-│   ├── catalog.yaml
-│   ├── {mcp,api}/
-│   ├── policies/
-│   ├── profiles/
-│   ├── runtime/
-│   └── servers/
-├── zaip-aios/
-│   ├── INDEX.md
-│   └── guides/
-├── .env.example
-└── .gitignore
-.agents/runtime/
-└── local/                               # estado local ignorado pelo Git
-    ├── claims/                          # claims atômicos de lifecycle
-    └── codex-telemetry-spool/v1/        # captura sanitizada, privada e recuperável
-\`\`\`
-
-| Caminho | Responsabilidade |
-| --- | --- |
-| \`config/\` | Configuração do projeto, perfis de clientes e agentes, maturidade de capacidades e lock de integridade dos arquivos gerenciados. |
-| \`dashboard/\` | Dashboard operacional local com Kanban, custos, tempo, tokens e grafo de rastreabilidade; lê os manifests de lifecycle e os detalhes canônicos por ID, sem criar uma verdade paralela nem reconstruir arquivos locais. |
-| \`design/\` | Design system do ZAIP, tokens visuais, catálogo de componentes e launcher local de inspeção. |
-| \`records/\` | Fonte canônica Git-native de PRDs, SPECs, Changes, Tasks, Executions e Runs. \`records/lifecycle\` contém manifests, índices, chunks e resumos para descoberta e paginação sem varrer o histórico. |
-| \`requirements/\` | Requisitos duráveis e Critérios de Aceite de lifecycle, execução, custos, contexto, dashboard, arquitetura e design system. |
-| \`rules/\` | Rules canônicas do framework e Rules locais do projeto, todas diretamente neste diretório. |
-| \`skills/\` | Workflows reutilizáveis que transformam conversas em Requirements, Tasks, SPECs e PRDs e orientam execução, revisão, segurança, custos, contexto e ferramentas. |
-| \`tools/\` | Catálogo de MCPs e APIs, políticas de aprovação e segredos, perfis de ativação, doctors e servidores locais gerados de maneira auditável. |
-| \`zaip-aios/\` | Handbook operacional com índice de baixo custo de contexto e guias de instalação, execução, revisão, agentes, custos, segurança e integração com Codex. |
-| \`.local/\` | Estado específico da máquina, como claims de lifecycle, writer ID e spool sanitizado de telemetria; fica fora do Git e não é uma fonte do dashboard. Segredos nunca devem ser gravados nos registros. |
-
-\`framework.lock.yaml\` é a referência mecânica dos arquivos administrados pela distribuição, enquanto \`project.yaml\` descreve o projeto consumidor. Rules presentes no lock pertencem ao framework e podem ser atualizadas pelo setup; Rules ausentes do lock são locais e devem ser preservadas. O agente começa por \`rules/core.md\`, usa os manifests canônicos em \`records/lifecycle\` para descoberta e só abre um registro histórico quando já possui seu ID explícito.
-
-O código canônico do dashboard vive em \`.agents/dashboard\`, separado das aplicações do produto. Ele possui somente \`apps/frontend\`; o servidor loopback read-only é uma implementação técnica em \`packages/local-runtime\`, e não um \`apps/backend\`. Os módulos \`operations\`, \`cost-monitor\` e \`traceability\` formam os read models em memória a partir dos manifests canônicos. Os launchers \`zaip-dashboard-windows.exe\`, \`zaip-dashboard-linux.sh\` e \`zaip-dashboard-mac.command\` permanecem diretamente em \`.agents/dashboard\` e também são instalados pelo CLI oficial.
-
-
-## Arquitetura das aplicações
-
-**Consultar layout, dependências e limites de código**
-
-Quando essas superfícies existirem, a estrutura canônica é:
-
-\`\`\`text
-apps/
-├── frontend/       # UI do produto e composition root do cliente
-├── backend/        # APIs, workers e composition roots de servidor
-└── site/           # landing page e site público, implantável separadamente
-modules/<area>/     # capacidades de negócio e seus contratos públicos
-packages/<library>/ # bibliotecas técnicas reutilizáveis
-tests/e2e/          # fluxos que atravessam aplicações
-\`\`\`
-
-A direção de dependência é \`apps -> modules -> packages\`. Essas pastas descrevem aplicações do produto consumidor, não o dashboard ZAIP. \`apps/site\` nunca importa o dashboard, não lê \`.agents\` e não depende de implementação privada do backend. Pastas de superfícies ausentes não precisam ser criadas vazias. Testes unitários ficam junto do código; jornadas cross-app ficam em \`tests/e2e\`.
-
-Arquivos-fonte com 401–800 linhas geram warning e arquivos com 801 ou mais linhas geram erro. O gate ignora código gerado, distribuição, vendor, dados e lockfiles. Exceções temporárias cobrem somente legado não-dashboard, têm limite congelado, responsável, motivo e validade.
-
-
-## Desenvolvimento do framework
-
-**Consultar contratos para mantenedores e contribuidores**
-
-Esta seção é destinada a mantenedores e contribuidores que alteram o código-fonte do próprio ZAIP-AIOS. Quem apenas instalou o framework dentro de outro repositório não precisa executar esta rotina para usar o Codex, criar Tasks, SPECs ou PRDs, acompanhar o dashboard ou executar o lifecycle normalmente.
-
-### Repositório-fonte e projeto consumidor
-
-- **Repositório-fonte:** contém a implementação oficial do ZAIP-AIOS, seus pacotes, dashboard, Rules, Requirements, skills, ferramentas e artefatos de distribuição. Mudanças intencionais nesses componentes precisam passar pelos gates de integridade, qualidade, testes e build.
-- **Projeto consumidor:** recebe uma versão publicada do framework dentro de \`.agents\`. O arquivo \`framework.lock.yaml\` é atualizado somente pelos fluxos transacionais de instalação ou upgrade do CLI; o projeto consumidor não executa \`sync:framework-lock\` para aceitar alterações locais.
-
-Configurações do projeto consumidor permanecem em \`.agents/config/project.yaml\`; Rules adicionais ficam diretamente em \`.agents/rules/*.md\` e não entram no lock do framework. Arquivos administrados pela distribuição não devem ser modificados e depois incorporados ao lock apenas para silenciar uma divergência.
-
-### Integridade dos arquivos gerenciados
-
-O \`framework.lock.yaml\` é um manifesto mecânico de integridade, não um lock de dependências como \`pnpm-lock.yaml\`. Ele registra os caminhos e hashes SHA-256 dos arquivos que pertencem à distribuição do ZAIP-AIOS, permitindo detectar alteração acidental, arquivo ausente ou conteúdo diferente do release esperado. Ele não armazena segredos, telemetria ou histórico de execução.
-
-Quando um mantenedor altera intencionalmente Rules, Requirements, skills ou outro arquivo gerenciado no repositório-fonte, deve revisar a mudança e então regenerar os hashes:
-
-\`\`\`bash
-pnpm sync:framework-lock
-pnpm validate:framework-lock
-\`\`\`
-
-\`sync:framework-lock\` grava o novo conjunto de caminhos e hashes no lock. \`validate:framework-lock\` é somente leitura: recalcula o estado esperado e falha se houver drift. O sync não deve ser usado automaticamente para esconder uma divergência; primeiro é necessário confirmar que a mudança pertence de fato ao framework e deve fazer parte da próxima distribuição.
-
-### Gates locais de qualidade
-
-| Comando | O que verifica |
-| --- | --- |
-| \`pnpm validate:framework-lock\` | Confirma que todos os arquivos gerenciados correspondem aos caminhos e hashes registrados no lock. |
-| \`pnpm validate:skills\` | Valida estrutura, nomes, frontmatter, interfaces, links, recursos e invariantes de segurança das skills. |
-| \`pnpm test:encoding\` | Detecta UTF-8 inválido, caracteres corrompidos, *mojibake* e outros problemas de codificação textual. |
-| \`pnpm validate:source-size\` | Mede arquivos de código, aplica limites e exceções temporárias e sinaliza componentes que precisam ser divididos em módulos mais coesos. |
-| \`pnpm lint\` | Verifica formatação, consistência e regras estáticas do código. |
-| \`pnpm typecheck\` | Executa a validação de tipos TypeScript nos pacotes do workspace. |
-| \`pnpm test\` | Executa os testes automatizados dos pacotes por meio do workspace. |
-| \`pnpm build\` | Compila e empacota os componentes, além de normalizar os textos gerados. |
-
-Uma validação local típica, depois de atualizar o lock quando necessário, é:
-
-\`\`\`bash
-pnpm validate:framework-lock
-pnpm validate:skills
-pnpm test:encoding
-pnpm validate:source-size
-pnpm lint
-pnpm typecheck
-pnpm test
-pnpm build
-\`\`\`
-
-Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\` executa a pipeline completa do repositório, incluindo gates adicionais de ferramentas, contratos, geração, workspace, paridade de runtime e testes de release. Essa pipeline apenas valida o lock; se um arquivo gerenciado tiver sido alterado intencionalmente, o sync deve acontecer antes.
-
-A arquitetura detalhada está resumida na seção [Arquitetura das aplicações](#arquitetura-das-aplicações) deste README.
-
-
-## Segurança com perfis de permissão
-
-O ZAIP-AIOS oferece dois perfis de permissão para equilibrar conveniência e contenção. O perfil selecionado por \`default_permissions\` define o limite técnico que o processo pode alcançar, enquanto instruções, Rules, hooks e skills continuam determinando o que o agente está autorizado a fazer.
-
-| Perfil | Filesystem nativo no Windows | Rede de comandos | Quando usar |
-| --- | --- | --- | --- |
-| \`zaip-aios-full-access\` | Escrita em \`C:\\\` inteiro, sujeita às ACLs e aos privilégios da conta Windows | Completa, com todos os domínios permitidos | Padrão humano; ainda exige autorização explícita para ações externas, destrutivas, publicação e elevação. |
-| \`zaip-aios-security\` | Escrita somente na raiz física deste repositório e seus descendentes, incluindo \`.git\`, \`.agents\` e \`.codex\`; escrita em \`~/.ssh\` apenas para fluxos Git/SSH autorizados | Limitada a \`github.com\` | Opt-in para menor privilégio; reinicie o Codex depois de selecioná-lo. |
-
-**Consultar funcionamento, riscos e defesa em profundidade**
-
-O perfil restrito usa uma tabela de permissões com a **raiz física absoluta** do repositório,
-não \`:workspace\` nem \`:workspace_roots\`. Essa escolha mantém \`.agents\`, \`.codex\` e \`.git\`
-editáveis no Windows sem liberar o restante de \`C:\\\`. Seu \`approval_policy = "never"\` não
-autoriza ações por si só: deploy, publicação, mutações remotas e ações destrutivas continuam
-dependendo de pedido explícito, instruções, Rules, hooks e skills.
-
-### Risco do \`zaip-aios-full-access\`
-
-\`zaip-aios-full-access\` é um perfil de maior risco. Ele pode alcançar outros repositórios,
-arquivos do usuário, diretórios de aplicações e do sistema, além de qualquer destino de rede que
-o host permita. Um comando incorreto, conteúdo externo malicioso ou uma dependência comprometida
-tem, portanto, impacto potencial muito maior. O perfil não concede privilégios de administrador e
-ainda respeita ACLs, políticas corporativas e arquivos em uso, mas essas barreiras não tornam o
-acesso equivalente ao perfil restrito.
-
-\`zaip-aios-full-access\` é o padrão humano e deve ser usado somente dentro da autoridade explícita
-do pedido. Quando uma operação puder ser executada com contenção de workspace, o usuário pode
-selecionar \`zaip-aios-security\` e reiniciar completamente o Codex para que o sandbox materialize o
-perfil escolhido. Não altere perfis apenas para contornar uma negação de permissão.
-
-### Defesa em profundidade
-
-Os dois perfis mantêm camadas compensatórias que reduzem risco, mas elas não substituem o
-isolamento nativo oferecido pelo perfil restrito:
-
-- carregamento da política somente em repositório confiável e escopo explícito em \`AGENTS.md\`;
-- hook \`PreToolUse\`, que bloqueia escapes do repositório, referências diretas a segredos, Git destrutivo, force push, mutações de OS, ACL, persistência, elevação e banco destrutivo;
-- regras Codex \`forbidden\`, instruções e skills que exigem autoridade explícita e limitam o escopo de cada operação;
-- deploy GitHub delimitado por pedido explícito, preflight, branch/remoto definidos e identidade SSH escopada;
-- proteção para que tokens, chaves privadas, credenciais e valores de ambiente não sejam impressos, registrados ou incluídos em commits;
-- Tasks, Changes, Executions, Runs, write scopes, threat model, rollback, testes negativos e review independente proporcionais ao risco;
-- subagentes com responsabilidades e escopos delimitados, além de adapters com hash, framework lock e gates de regressão;
-- controles remanescentes do sistema operacional, como ACLs, privilégios da conta e políticas do host.
-
-O hook de segurança \`PreToolUse\` também permanece ativo no perfil full-access, sem reduzir suas permissões nativas; ele bloqueia classes destrutivas, segredos, publicação e elevação sem autorização. Os hooks de lifecycle de subagentes permanecem ativos como
-defesa em profundidade e para atribuição/telemetria. Browser, Computer Use, MCPs e demais
-integrações têm superfícies próprias e devem ser habilitados e usados apenas quando necessários.
-Para isolamento forte contra erros de escopo ou código malicioso, use o perfil restrito e, quando
-o risco justificar, uma conta, VM ou controles externos de rede e filesystem dedicados.
-
-O modelo de ameaça, a matriz allow/deny, todas as camadas, limitações, operação segura,
-rollout, rollback e comandos de verificação estão documentados no
-[guia completo de segurança dos perfis ZAIP-AIOS](.agents/zaip-aios/guides/10-seguranca.md).
-
-
-## Automação e integrações opcionais
-
-### Agendamento horário da fila pronta
-
-No Codex Desktop, o agendamento horário da fila pronta é configurado pela skill \`$zaip-skill-instalar-agendamento\` em uma única conversa no checkout local. A skill usa a automação nativa de tarefas agendadas para criar ou atualizar uma tarefa standalone com nome estável; ela não duplica registros e falha fechada se a capacidade \`automation_update\` não estiver disponível. A tarefa agendada chama explicitamente \`$zaip-skill-executar-fila-pronta\` em cada rodada horária.
-
-A rodada processa sequencialmente todo o snapshot elegível: primeiro PRDs em \`ready\`, depois SPECs \`ready\` independentes e, por último, Tasks avulsas materializadas em **Pronto para Executar**. Itens descendentes, ativos, bloqueados, falhos ou terminais ficam fora. Em **Dashboard > Trabalho (Kanban) > Pronto para Executar**, a prioridade é definida pela numeração de cima para baixo dentro do tier PRD/SPEC/Task e persiste para o scheduler em \`.agents/dashboard/work-priority.json\`; os controles acessíveis de ordenação atualizam essa numeração, e itens sem número vão para o fim pelo fallback determinístico. Um lock/lease local evita sobreposição entre rodadas.
-
-O repositório versiona esse contrato, mas não instala um relógio em cada clone. A tarefa agendada pertence à máquina/usuário que a criou e depende da máquina ligada, do Codex Desktop em execução e da automação nativa disponível; sem eles, a skill falha fechada e não promete execução futura.
-
-### Codex, documentação oficial e navegador
-
-O arquivo \`.codex/config.toml\` é uma configuração de projeto carregada pelo Codex somente quando o repositório é confiável. Na configuração atual do ZAIP-AIOS, ele orienta a descoberta de \`AGENTS.md\` e habilita o MCP oficial e read-only da documentação OpenAI, permitindo que o agente consulte informações atuais sobre Codex, modelos, APIs, SDKs e MCP sem depender apenas da memória do modelo. O instalador também disponibiliza a skill ZAIP de descoberta, enquanto o próprio Codex fornece recursos estáveis como shell, subagentes, apps, hooks e busca web conforme a superfície, a conta e as políticas do ambiente.
-
-O navegador integrado não é ativado silenciosamente pelo CLI nem por \`.codex/config.toml\`. No app Codex/ChatGPT para desktop, o plugin Browser permite abrir páginas e aplicações locais, clicar, digitar, inspecionar o estado renderizado, capturar screenshots e verificar visualmente uma implementação, sempre sujeito às permissões de sites e às confirmações de ações sensíveis. O navegador integrado não está disponível no Codex CLI nem na extensão de IDE. Para automação por Playwright ou outro MCP de navegador, \`.agents/tools\` inclui um manifesto opt-in desabilitado por padrão; a implementação precisa ser escolhida, auditada e validada antes da ativação.
-
-## Visualização opcional da rastreabilidade no Obsidian
-
-A skill \`criar-pasta-obsidian\` gera em \`.local/obsidian/vault\` uma projeção local e reconstruível das relações entre PRDs, SPECs, Changes, Tasks, Executions, Runs, requisitos, evidências e testes. Ela não transforma o Obsidian em fonte de verdade, não duplica os corpos completos dos registros e não exige que o aplicativo esteja instalado para gerar ou validar a pasta.
-
-Na raiz do repositório, a geração ou atualização do vault utiliza:
-
-\`\`\`powershell
-node .agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs
-\`\`\`
-
-O [guia de Obsidian para rastreabilidade ZAIP](guide/CRIAR-PASTA-OBSIDIAN.md) documenta a instalação do aplicativo, a abertura da pasta como vault, a geração de uma única Task e a atualização da projeção após um \`git pull\`.
-`,S=t(),C=Object.assign({"../../../../zaip-aios/guides/01-primeiros-passos.md":r,"../../../../zaip-aios/guides/02-requirements.md":i,"../../../../zaip-aios/guides/03-tasks.md":a,"../../../../zaip-aios/guides/04-specs.md":o,"../../../../zaip-aios/guides/05-prds.md":s,"../../../../zaip-aios/guides/06-execucao.md":c,"../../../../zaip-aios/guides/07-revisao-e-validacao.md":l,"../../../../zaip-aios/guides/08-contexto-e-tokens.md":u,"../../../../zaip-aios/guides/09-agentes-e-squads.md":d,"../../../../zaip-aios/guides/10-seguranca.md":f,"../../../../zaip-aios/guides/11-observabilidade-e-custos.md":p,"../../../../zaip-aios/guides/12-instalacao-e-upgrade.md":m,"../../../../zaip-aios/guides/13-boas-praticas.md":h,"../../../../zaip-aios/guides/14-troubleshooting.md":g,"../../../../zaip-aios/guides/15-tools-e-codex.md":_,"../../../../zaip-aios/guides/16-lifecycle-e-reconciliacao.md":v,"../../../../zaip-aios/guides/17-como-o-custo-e-calculado.md":y});function w({locale:e,onClose:t}){let r=(0,b.useMemo)(()=>n(e,x,C),[e]),i=r.filter(e=>e.id!==`readme`),[a,o]=(0,b.useState)(`readme`),[s,c]=(0,b.useState)(`rendered`),l=r.find(e=>e.id===a)??r[0];return(0,S.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,S.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,S.jsxs)(`header`,{children:[(0,S.jsxs)(`div`,{children:[(0,S.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,S.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,S.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,S.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,S.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,S.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,S.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,S.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,S.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,S.jsxs)(`article`,{children:[(0,S.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,S.jsx)(`h3`,{children:l?.title}),(0,S.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,S.jsx)(`button`,{"aria-pressed":s===`rendered`,className:s===`rendered`?`is-active`:void 0,onClick:()=>c(`rendered`),type:`button`,children:e===`pt-BR`?`Renderizado`:`Rendered`}),(0,S.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,S.jsx)(`div`,{className:`dashboard-help-sections`,children:M(l?.content??``,e).map(e=>(0,S.jsxs)(`section`,{children:[(0,S.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,S.jsx)(T,{content:e.content}):(0,S.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function T({content:e}){return j(E(e),A).map(({key:e,value:t})=>t.kind===`table`?(0,S.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,S.jsxs)(`table`,{children:[(0,S.jsx)(`thead`,{children:(0,S.jsx)(`tr`,{children:j(t.headers,e=>e).map(({key:e,value:t})=>(0,S.jsx)(`th`,{children:k(t)},e))})}),(0,S.jsx)(`tbody`,{children:j(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,S.jsx)(`tr`,{children:j(t,e=>e).map(({key:e,value:t})=>(0,S.jsx)(`td`,{children:k(t)},e))},e))})]})},e):(0,S.jsx)(`pre`,{children:t.content},e))}function E(e){let t=e.split(`
-`),n=[],r=[],i=()=>{let e=r.join(`
-`).trim();e&&n.push({kind:`text`,content:e}),r=[]};for(let e=0;e<t.length;e+=1){let a=t[e],o=t[e+1];if(a?.includes(`|`)&&o&&D(o)){i();let r=O(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(O(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function D(e){return O(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function O(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function k(e){return j(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,S.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,S.jsx)(b.Fragment,{children:t},e))}function A(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function j(e,t){let n=new Map;return e.map(e=>{let r=t(e),i=(n.get(r)??0)+1;return n.set(r,i),{key:`${r}#${i}`,value:e}})}function M(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`
-`),i=r[0]?.match(/^#{1,2}\s+(.+)$/)?.[1];return{title:i??(n===0?t===`pt-BR`?`Introdução`:`Introduction`:t===`pt-BR`?`Seção ${n+1}`:`Section ${n+1}`),content:i?r.slice(1).join(`
-`).trim():r.join(`
-`).trim()}})}export{w as DashboardHelpDialog};