@zaip-ai/cli 1.0.7 → 1.0.8

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-Cv-JcoxP.js → DashboardHelpDialog-Cs6dzDmW.js}

@@ -1,4 +1,4 @@
-import{n as e,t}from"./index-8AzCnl3a.js";import{t as n}from"./dashboard-localization-C98LGC-Q.js";var r=`# Primeiros passos
+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.
@@ -155,8 +155,8 @@ O ZAIP-AIOS oferece dois perfis atuais:
 
 | Perfil | Filesystem nativo | Rede de comandos | Uso recomendado |
 | --- | --- | --- | --- |
-| \`zaip-aios-security\` | Escrita na raiz física do repositório, incluindo \`.git\`, \`.agents\`, \`.codex\` e demais arquivos ocultos | Limitada a \`github.com\` | Trabalho normal e princípio de menor privilégio, incluindo deploy GitHub autorizado |
-| \`zaip-aios-full-access\` | Escrita em \`C:\\\` inteiro no Windows, quando as permissões do sistema permitirem | Completa, todos os domínios | Correção de configuração, diagnóstico ou operação que realmente exija acesso fora do workspace |
+| \`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
@@ -219,7 +219,11 @@ pelo sandbox nativo:
 - o impacto máximo de uma edição comum fica contido no repositório;
 - todas as camadas ZAIP descritas abaixo continuam ativas.
 
-Esse perfil deve ser o padrão para desenvolvimento, revisão, testes, manutenção normal e deploy GitHub autorizado quando a escrita na identidade SSH local for necessária. 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.
+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\`
 
@@ -267,8 +271,8 @@ conteúdo malicioso, dependência comprometida ou erro de escopo pode tentar:
 - enviar dados pela rede;
 - ampliar o impacto de uma falha de supply chain.
 
-Ele deve ser ativado somente quando o perfil restrito não consegue executar uma operação
-legítima e explicitamente autorizada. Após a correção, volte para \`zaip-aios-security\`.
+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
 
@@ -279,7 +283,7 @@ O acesso completo é mitigado por defesa em profundidade, mas nenhuma camada tor
    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\`:** valida comandos e patches antes da execução; bloqueia escapes do
+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
@@ -308,7 +312,7 @@ Use \`zaip-aios-security\` quando:
 - comandos precisam, no máximo, alcançar \`github.com\` para operações Git/SSH autorizadas;
 - menor privilégio é desejado.
 
-Use \`zaip-aios-full-access\` apenas quando:
+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;
@@ -378,31 +382,102 @@ ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
 - 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=e(),b=`# ZAIP-AIOS para Codex (Git-native)
+`,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 Git-native de engenharia autônoma para o Codex, criado para reduzir o custo e o tempo necessários à execução de trabalhos complexos. Sua meta é gerar uma economia estimada de 25% a 40% no consumo bruto de tokens ao longo de todo o ciclo de uma tarefa executada de maneira autônoma, e não apenas reduzir o custo de uma chamada isolada ao modelo.
+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%">
 
-Por meio de Graph Engineering, o sistema interpreta a demanda, decompõe entregas complexas em Tasks menores organizadas em uma DAG e seleciona, entre 18 agentes especializados, conforme capabilities, especialidade, escopo de escrita, dependências e risco declarados. Com Loop Engineering, o ZAIP-AIOS analisa, durante uma execução de Task, falhas, bloqueios e retrabalho. Quando a execução se origina de PRD ou SPEC e \`model_orchestration.mode:auto\` está ativo, ela começa pelo caminho mais econômico que preserve os gates de qualidade e pode escalar automaticamente entre os modelos GPT-5.6 Luna, Terra e Sol, com níveis de esforço low, medium, high ou xhigh, conforme os sinais da execução. Conversation e Task-first preservam a seleção manual do host/Codex.
+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.
 
-Requisitos, decisões, testes, revisões e evidências permanecem versionados e rastreáveis no Git, salvando o histórico sem precisar de um banco de dados. Uma tarefa só é considerada concluída quando existem provas objetivas e verificáveis de que os critérios 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) |
-| Fazer uma alteração pontual | [Três formas de executar](#três-formas-de-executar) e [regras práticas](#regras-práticas-de-operação) |
+| 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) |
-| Conhecer os 18 agentes | [Personas e roteamento de agentes](#personas-e-roteamento-de-agentes) |
-| Entender estados, Runs e encerramento | [Cadeia completa de execução](#cadeia-completa-de-execução) e [Fluxos](#fluxos) |
-| Consultar custos, cobertura e rastreabilidade | [Dashboard Local](#dashboard-local) e [Telemetria Git-native](docs/TELEMETRIA-GIT-NATIVE.md) |
+| 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
+\`\`\`
 
-## Tese central
+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 |
 | --- | --- | --- |
@@ -410,15 +485,17 @@ Requisitos, decisões, testes, revisões e evidências permanecem versionados e
 | **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. |
 
-Essa separação é intencional: o GPT-5.6 fornece a inteligência, o Codex fornece o harness oficial de execução e o ZAIP-AIOS fornece a metodologia, a governança e a memória verificável do desenvolvimento. O ZAIP-AIOS define **o que deve ser feito, como o trabalho deve ser organizado, quais regras arquiteturais devem 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 continuam disponíveis para comparação e compatibilidade por meio de artefatos portáveis, sem reduzir o caminho oficial ao menor denominador comum.
+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 catálogo oficial de agentes fica em .agents/config/agents/catalog.yaml, separando identidade técnica da persona editável. O Dashboard permite alterar nome e cargo, recalcula automaticamente os identificadores derivados e impede mudanças inválidas. O comando adapters build atualiza as configurações locais do Codex sem sobrescrever preferências externas ao bloco gerenciado.
+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.
 
-O roteamento ocorre por especialidade e escopo: Doug cuida do frontend, Will do backend, Jonny de website, SEO e Agent Readiness, e Manu do design system. Bia é responsável por PRDs e Rafa por SPECs. A criação ou revisão desses artefatos exige uma Run ativa, delegada ao especialista correto, sem reutilização de execuções históricas ou atribuições artificiais.
+### Os 23 agentes
 
-| Foto | # | Persona / função | Função |
+| 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 |
@@ -428,30 +505,52 @@ O roteamento ocorre por especialidade e escopo: Doug cuida do frontend, Will do
 | <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 grounded |
+| <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/LPs, SEO, GEO e readiness |
+| <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 |
 
-Consulte [Catálogo de agentes](docs/AGENT-CATALOG.md) para o contrato completo, capacidades e regras de roteamento.
+O [Catálogo de agentes](docs/AGENT-CATALOG.md) reúne as especialidades e responsabilidades dos agentes disponíveis no ZAIP-AIOS.
 
-O fluxo pode começar por uma **Task**, por um **PRD** (*Product Requirements Document*, ou Documento de Requisitos do Produto) ou por uma **SPEC**, a especificação técnica desenvolvida segundo o conceito de **Spec-Driven Development (SDD)**. O PRD explica o problema, o resultado esperado, o contexto e os critérios do produto; a SPEC transforma essa intenção em escopo técnico, solução, Critérios de Aceite, Changes e uma DAG de Tasks executáveis.
+### Squads organizacionais
 
-O ZAIP-AIOS não exige serviço em VPS, runtime concorrente ou roteamento obrigatório de modelos por API. O Codex permanece como host de execução; o ZAIP-AIOS acrescenta método, memória operacional, governança, rastreabilidade e observabilidade ao que acontece no projeto. O dashboard oferece Trabalho (Kanban) e Trabalho (Lista) para acompanhar Tasks, SPECs e PRDs, além do status, das dependências, dos bloqueios e do progresso do trabalho que múltiplos agentes executam de forma autônoma.
+<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">
 
-> O desenvolvimento pode utilizar os tokens incluídos na conta ChatGPT/Codex, sem exigir consumo direto de API. O dashboard acompanha tokens, tempo e custo por tarefa e calcula o custo equivalente estimado de quanto o mesmo consumo representaria se fosse cobrado pelos preços de API. Essa comparação ajuda a prever custos antes de adotar uma execução via API e a dimensionar o benefício econômico aparente do plano em relação ao preço público da API, uma estimativa comparativa, não uma medição oficial de subsídio ou cobrança da OpenAI.
+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 local funciona como uma projeção dos registros Git-native, sem criar uma fonte de verdade paralela. Todas as informações exibidas podem ser reconstruídas a partir dos arquivos do projeto.
+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.
 
-As telas permitem acompanhar a execução, analisar consumo, investigar rastreabilidade e configurar o projeto, mantendo o Git como fonte oficial.
 
 ### Kanban
 
@@ -459,7 +558,7 @@ Organiza PRDs, SPECs e Tasks por estágio, destacando execução, verificação,
 
 <img src=".agents/config/src/dashboard_pt_2_kanban.png" alt="Dashboard ZAIP-AIOS, Kanban" width="100%">
 
-É a visão operacional com Trabalho (Kanban) e Trabalho (Lista). Ambas preservam os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista torna comparáveis status, origem, risco, Runs, Sub-Runs, tempo, tokens, custo e cobertura; o Kanban mantém a leitura por estágio. O usuário pode navegar pelos três níveis de execução, identificar bloqueios e abrir os detalhes rastreáveis de cada item.
+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
 
@@ -467,13 +566,18 @@ Consolida tokens, duração, custo equivalente estimado e cobertura por período
 
 <img src=".agents/config/src/dashboard_pt_3_monitor_custos.png" alt="Dashboard ZAIP-AIOS, Monitor de Custos" width="100%">
 
-Consolida tokens, tempo e custo por Run, Task, SPEC e PRD e permite analisar fases de conversa, planejamento e execução, além de trabalho novo e rework. Quando o Codex consome tokens ou franquia da conta em vez de cobrar uma API, o módulo calcula, quando há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. Essa estimativa serve para gestão e comparação; ela nunca é apresentada como cobrança real. As projeções preservam agregações por dia, mês e ano, médias, concentração de consumo e cobertura; valores não observados continuam \`unknown\`, nunca viram zero artificialmente.
+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. Consulte [Telemetria Git-native do Codex](docs/TELEMETRIA-GIT-NATIVE.md)
-para contratos, armazenamento, integridade, recuperação e limites do rollout.
+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
 
@@ -483,16 +587,9 @@ Relaciona intenção, planejamento, execução, decisões, validações e evidê
 
 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.
 
-### Configurar Agentes
+## O custo que importa: concluir a tarefa
 
-Apresenta o catálogo dos 18 agentes e permite configurar persona, modelo e esforço dentro dos contratos de identidade e roteamento do projeto.
-
-<img src=".agents/config/src/dashboard_pt_configuracao_agentes.png" alt="Dashboard ZAIP-AIOS, Configurar Agentes" width="100%">
-
-
-## Economia por tarefa: custo para concluir, não custo por chamada
-
-O preço de uma chamada, ou mesmo o preço de um modelo, não mede o custo real de desenvolvimento com IA. Uma Task costuma exigir várias chamadas: entendimento do pedido, leitura de contexto, implementação, execução de testes, correção, review, validação e registro da evidência. Por isso, o ZAIP-AIOS mede e compara **Runs, fases e rework por Task, SPEC e PRD**, em vez de celebrar uma chamada isolada barata.
+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 é:
 
@@ -502,7 +599,7 @@ custo da tarefa concluída = modelo + ferramentas + tempo humano + rework + cust
 
 ## PRD como interface de autonomia
 
-O PRD permite que o usuário governe o trabalho sem revisar cada decisão técnica.
+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.
 
@@ -515,6 +612,8 @@ Quando diz **“Crie um PRD”**, a IA faz até cinco perguntas importantes por
 
 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.
@@ -558,33 +657,50 @@ Toda criação de PRD ou SPEC é vinculada à Run responsável por meio do campo
 
 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
 
-Uma resposta pode parecer concluída mesmo sem testes, revisão ou comprovação dos Critérios de Aceite.
+## 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
 
-Esse problema costuma reaparecer depois na forma de bugs, investigações, correções, regressões e novas rodadas de contexto.
+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.
 
-Tests, reviews, checks e Evidence adicionam um custo inicial, mas reduzem a chance e o impacto do retrabalho. Quando ele ainda ocorre, permanece registrado e rastreável.
+<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
 
-### Economia medida e meta central por tarefa
+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.
 
-Cada indicador abaixo mede uma parte diferente do fluxo. A primeira linha apresenta a faixa fundamentada/estimada para uma Task completa. As demais são medições reproduzíveis de contexto e payload. As medições da tabela são um snapshot de **13/07/2026**; elas não descrevem automaticamente a população atual de skills ou do repositório.
+<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">
 
-Os percentuais não devem ser somados, pois as otimizações podem ocorrer simultaneamente no mesmo fluxo.
+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.
 
-Com ciclos constantes, as otimizações de payload medidas sustentam um piso conservador de **8%–15%**. Esse piso não é uma medição end-to-end da Task: a faixa de **25%–40%** é uma estimativa fundamentada para a Task completa, baseada no potencial adicional de reduzir ciclos e retrabalho com contexto seletivo, navegação compacta, budgets e checkpoints, verificação em lote e critérios/evidências claros.
+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 |
 | --- | --- | ---: | ---: | ---: | --- |
-| **Task completa, todos os ciclos de modelo** | Entendimento, contexto, implementação, testes, correções, review e evidências até concluir uma Task. | Índice normalizado (**baseline = 100**) | **60–75** | **25%–40%** | **Estimativa fundamentada**; validar com Tasks pareadas piloto e cálculo amostral com telemetria coberta. |
+| **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. |
 
-A faixa de **25%–40%** aplica-se aos tokens brutos de todos os ciclos necessários para entregar uma Task, e não ao preço de uma única chamada. É uma estimativa operacional útil para planejamento, não uma economia financeira comprovada por tarefa nem uma comparação já demonstrada contra um baseline pareado.
 
-Para uma comparação válida, execute a mesma classe de Task em dois braços, por exemplo, Codex normal e Codex + ZAIP-AIOS, com o mesmo modelo, repositório, Critérios de Aceite e janela de observação. Compare:
+### 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;
@@ -592,7 +708,43 @@ Para uma comparação válida, execute a mesma classe de Task em dois braços, p
 - 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\`; ele não converte ausência de telemetria em custo zero. Isso evita que uma estimativa de economia esconda custo de provider, rework ou qualidade não observados. Consulte também [a auditoria de tokens e performance](analysis/verificacao-auditoria-tokens-performance-zaip-aios-2026-07-13.md).
+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
 
@@ -615,6 +767,10 @@ O método mantém intenção e execução separadas. PRD e SPEC explicam o que s
 
 ## 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. |
@@ -630,20 +786,28 @@ O método mantém intenção e execução separadas. PRD e SPEC explicam o que s
 | **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.
@@ -659,11 +823,11 @@ Toda mensagem do usuário cria uma Execution e uma Run de captura. Perguntas, fe
 
 <img src=".agents/config/src/zaip-aios-obsidian.png" alt="Zaip AIOS no Obsidian" width="100%">
 
-O ZAIP-AIOS aplica **Graph Engineering** para coordenar 18 agentes especializados como um grafo de execução governado por capacidades, dependências, criticidade, custo e evidências. O papel de **Graph Engineer** é exercido pela orquestração: a cada etapa, ela interpreta a demanda e escolhe o menor conjunto de agentes necessário. A calibração automática entre **Luna**, **Terra** e **Sol** e entre os esforços **low**, **medium**, **high** e **xhigh** aplica-se somente a Agent Runs originadas de PRD/SPEC quando \`model_orchestration.mode:auto\` está ativo; Conversation e Task-first preservam a seleção manual do host/Codex.
+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 é governada: Dave é a raiz única, cada executor recebe apenas o escopo necessário, Nanda realiza a revisão independente, especialistas de assurance entram somente quando existem sinais objetivos e Gui encerra o fluxo por último. Em execuções originadas por PRD ou SPEC, os sinais de fase, complexidade, ambiguidade, transversalidade, rework, impacto e rollback alimentam automaticamente a seleção. Tasks avulsas e conversas preservam a seleção manual do host enquanto não possuem um \`model_profile\` governado equivalente.
+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 papel de **Loop Engineer** aparece quando a primeira tentativa não satisfaz os gates. O resultado volta para Dave, o rework é classificado e uma nova Agent Run pode subir de **Luna → Terra → Sol** ou de **low → medium → high → xhigh** quando os novos sinais justificarem o custo. O modelo não muda silenciosamente dentro da mesma Run: cada tentativa permanece auditável, com configuração, tokens, custo, evidências e resultado próprios. Assim, a execução é autônoma dentro de limites explícitos, começando pelo caminho mais barato que preserve a qualidade e escalando somente quando a evidência da tentativa exigir.
+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
 
@@ -711,8 +875,7 @@ flowchart LR
 
 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.
 
-<details>
-<summary><strong>Formas de entrada</strong></summary>
+**Formas de entrada**
 
 \`\`\`mermaid
 flowchart TD
@@ -737,10 +900,8 @@ flowchart TD
     R --> D
 \`\`\`
 
-</details>
 
-<details>
-<summary><strong>Planejamento com PRD e SPEC</strong></summary>
+**Planejamento com PRD e SPEC**
 
 \`\`\`mermaid
 flowchart LR
@@ -758,10 +919,8 @@ flowchart LR
     N --> G["Gui"]
 \`\`\`
 
-</details>
 
-<details>
-<summary><strong>Demanda crítica e transversal</strong></summary>
+**Demanda crítica e transversal**
 
 \`\`\`mermaid
 flowchart TD
@@ -797,10 +956,8 @@ flowchart TD
 
 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.
 
-</details>
 
-<details>
-<summary><strong>Seleção de modelo e esforço</strong></summary>
+**Seleção de modelo e esforço**
 
 \`\`\`mermaid
 flowchart TD
@@ -833,10 +990,8 @@ Esforço = criticidade + dificuldade de raciocínio + custo do erro
 Assurance = criticidade + impacto + rollback
 \`\`\`
 
-</details>
 
-<details>
-<summary><strong>Matriz recomendada por agente</strong></summary>
+**Matriz recomendada por agente**
 
 | Agente | Lite | Standard | Crítico |
 |---|---|---|---|
@@ -858,11 +1013,14 @@ Assurance = criticidade + impacto + rollback
 | 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 |
 
-</details>
 
-<details>
-<summary><strong>Perfis por criticidade</strong></summary>
+**Perfis por criticidade**
 
 | Perfil | Orquestração | Execução | Review | Assurance adicional | Finalização |
 |---|---|---|---|---|---|
@@ -870,9 +1028,10 @@ Assurance = criticidade + impacto + rollback
 | 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 |
 
-</details>
 
-### Grafo unificado dos 18 agentes
+**Consultar o grafo unificado dos 23 agentes**
+
+### Grafo unificado dos 23 agentes
 
 \`\`\`mermaid
 flowchart TD
@@ -895,6 +1054,11 @@ flowchart TD
     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
@@ -908,6 +1072,11 @@ flowchart TD
     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"]
@@ -932,10 +1101,15 @@ flowchart TD
     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 18 em toda demanda. Consulte o [guia completo de Graph Engineering dos agentes](guide/GRAPH-ENGINEERING-AGENTES-ZAIP.md) para os contratos dos nós, cenários detalhados e regras de escalada.
+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.
@@ -1036,7 +1210,7 @@ Bloqueio e rework não descartam o que já foi produzido. Eles retornam ao Orche
 
 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. Para uma DAG manual, construa e valide o plano antes de preparar a Task:
+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
@@ -1048,7 +1222,7 @@ Um PRD precisa ter pelo menos uma SPEC para chegar a \`ready\`, \`active\` ou \`
 
 #### Refinamento Git-native
 
-Enquanto PRD ou SPEC estiverem em \`draft\`, refine diretamente o Markdown versionado, incrementando \`revision\` e \`updated_at\`. Depois de \`prepare\`, não altere silenciosamente o plano materializado: uma mudança semântica exige a transição explícita suportada de volta para draft ou a criação de um novo draft.
+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
 
@@ -1078,12 +1252,19 @@ zaip cqrs validate # quando aplicável
 
 #### Observabilidade e projeções
 
-Use \`zaip run list\` para navegar pelas Runs e \`zaip run aggregate\` para agregar tokens e custos no escopo desejado. O dashboard, o Kanban e o Cost Monitor são projeções do estado Git-native; eles não substituem os records canônicos.
+\`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/
@@ -1092,7 +1273,9 @@ Conversation, Planning e Execution permanecem separados. Tokens, custos, tempo,
 │   ├── agents/catalog.yaml
 │   └── profiles/clients.yaml
 ├── dashboard/
-│   ├── zaip-dashboard.exe
+│   ├── zaip-dashboard-windows.exe
+│   ├── zaip-dashboard-linux.sh
+│   ├── zaip-dashboard-mac.command
 │   ├── apps/frontend/
 │   ├── modules/{operations,cost-monitor,traceability}/
 │   ├── packages/
@@ -1150,11 +1333,14 @@ Conversation, Planning e Execution permanecem separados. Tokens, custos, tempo,
 
 \`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. \`zaip-dashboard.exe\` permanece diretamente em \`.agents/dashboard\` e também é instalado pelo CLI oficial.
+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
 
-Quando essas superfícies existirem, use a estrutura canônica:
+**Consultar layout, dependências e limites de código**
+
+Quando essas superfícies existirem, a estrutura canônica é:
 
 \`\`\`text
 apps/
@@ -1170,8 +1356,11 @@ A direção de dependência é \`apps -> modules -> packages\`. Essas pastas des
 
 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
@@ -1224,16 +1413,17 @@ Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\`
 
 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 gera \`.codex/config.toml\` com dois perfis de permissão. O perfil efetivo é
-selecionado por \`default_permissions\`; ele define o limite técnico que o processo pode alcançar,
-enquanto instruções, Rules, hooks e skills definem o que o agente está autorizado a fazer.
+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-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\` | Desenvolvimento, revisão, testes e deploy GitHub autorizado: é o perfil recomendado para o trabalho normal. |
-| \`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 | Exceção temporária para uma operação explicitamente autorizada que realmente exija acesso fora do workspace. |
+| \`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\`
@@ -1250,10 +1440,10 @@ tem, portanto, impacto potencial muito maior. O perfil não concede privilégios
 ainda respeita ACLs, políticas corporativas e arquivos em uso, mas essas barreiras não tornam o
 acesso equivalente ao perfil restrito.
 
-Use-o somente depois de diagnosticar que \`zaip-aios-security\` não atende uma necessidade legítima
-e explicitamente autorizada. Não o selecione apenas para contornar uma negação de permissão. Ao
-concluir a operação excepcional, retorne para \`zaip-aios-security\` e reinicie completamente o
-Codex para que o sandbox materialize o perfil selecionado.
+\`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
 
@@ -1269,7 +1459,7 @@ isolamento nativo oferecido pelo perfil restrito:
 - 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\` e os hooks de lifecycle de subagentes permanecem ativos como
+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
@@ -1279,21 +1469,16 @@ O modelo de ameaça, a matriz allow/deny, todas as camadas, limitações, opera
 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).
 
-## Instalação em um comando
-
-Com Node.js 22 ou mais recente e Git disponíveis, abra o terminal na raiz do repositório que receberá o ZAIP-AIOS e execute:
 
-\`\`\`bash
-npx @zaip-ai/cli@latest init
-\`\`\`
+## Automação e integrações opcionais
 
-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.
+### Agendamento horário da fila pronta
 
-Cada release do CLI leva seu próprio template verificado. A árvore documentada abaixo representa o estado atual deste repositório-fonte; uma funcionalidade recém-integrada passa a chegar pelo mesmo comando assim que a release correspondente é publicada.
+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.
 
-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. Ele também instala os adapters \`AGENTS.md\` e \`CLAUDE.md\`, a skill 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. Esses arquivos apontam cada cliente 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.
+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.
 
-Depois da instalação, use o [índice operacional](.agents/zaip-aios/INDEX.md) para abrir somente o guia necessário sobre primeiros passos, execução, revisão, custos, ferramentas, diagnóstico ou atualização.
+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
 
@@ -1305,16 +1490,16 @@ O navegador integrado não é ativado silenciosamente pelo CLI nem por \`.codex/
 
 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, gere ou atualize o vault com:
+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
 \`\`\`
 
-Cada pessoa que baixar o repositório pode executar esse comando no próprio computador. Para instalar o aplicativo, abrir a pasta correta como vault, gerar somente uma Task e atualizar a projeção depois de um \`git pull\`, consulte o [guia de Obsidian para rastreabilidade ZAIP](guide/CRIAR-PASTA-OBSIDIAN.md).
-`,x=t(),S=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});function C({locale:e,onClose:t}){let r=(0,y.useMemo)(()=>n(e,b,S),[e]),i=r.filter(e=>e.id!==`readme`),[a,o]=(0,y.useState)(`readme`),[s,c]=(0,y.useState)(`rendered`),l=r.find(e=>e.id===a)??r[0];return(0,x.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,x.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,x.jsxs)(`header`,{children:[(0,x.jsxs)(`div`,{children:[(0,x.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,x.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,x.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,x.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,x.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,x.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,x.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,x.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,x.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,x.jsxs)(`article`,{children:[(0,x.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,x.jsx)(`h3`,{children:l?.title}),(0,x.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,x.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,x.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,x.jsx)(`div`,{className:`dashboard-help-sections`,children:j(l?.content??``,e).map(e=>(0,x.jsxs)(`section`,{children:[(0,x.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,x.jsx)(w,{content:e.content}):(0,x.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function w({content:e}){return A(T(e),k).map(({key:e,value:t})=>t.kind===`table`?(0,x.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,x.jsxs)(`table`,{children:[(0,x.jsx)(`thead`,{children:(0,x.jsx)(`tr`,{children:A(t.headers,e=>e).map(({key:e,value:t})=>(0,x.jsx)(`th`,{children:O(t)},e))})}),(0,x.jsx)(`tbody`,{children:A(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,x.jsx)(`tr`,{children:A(t,e=>e).map(({key:e,value:t})=>(0,x.jsx)(`td`,{children:O(t)},e))},e))})]})},e):(0,x.jsx)(`pre`,{children:t.content},e))}function T(e){let t=e.split(`
+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&&E(o)){i();let r=D(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(D(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function E(e){return D(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function D(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function O(e){return A(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,x.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,x.jsx)(y.Fragment,{children:t},e))}function k(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function A(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 j(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`
+`).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{C as DashboardHelpDialog};
+`).trim()}})}export{w as DashboardHelpDialog};