npm - @zaip-ai/cli - Versions diffs - 1.3.5 → 1.3.7 - Mend

@zaip-ai/cli 1.3.5 → 1.3.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (76) hide show

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-CKO47D5s.js → DashboardHelpDialog--czwAlcH.js} RENAMED Viewed

@@ -1,4 +1,4 @@
-import{S as e,b as t}from"./cost-monitor-Csj6LiAt.js";import{t as n}from"./dashboard-localization-CLJ0lT9v.js";var r=`# Primeiros passos
+import{S as e,b as t}from"./cost-monitor-C09KmlSw.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.
@@ -1637,728 +1637,728 @@ node scripts/validate-text-encoding.mjs
 Os comandos acima são gates de desenvolvimento. A confirmação operacional continua sendo a
 combinação de hashes válidos, cobertura explícita e leitura do período real no Dashboard.
-`,A='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento é a referência pública do lifecycle implementado pelo ZAIP-AIOS. Status persistido, Run, coluna do Kanban e reconciliação possuem responsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\n`implemente` sem alvo abre somente uma Conversation de planejamento; em `draft` finaliza o plano sem executar, em `ready` executa e em `active|blocked|failed` continua, retoma ou cria rework. `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada Execution usa uma Run raiz do `zaip-agent-orchestrator`. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. Finalizador ausente, incompleto ou falho resulta em `blocked`, nunca em Task presa em `executing` ou `verifying`.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nExemplo:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração é uma interrupção retomável e resulta em `blocked`. “Cancelar a Task” é uma decisão explícita e resulta em `cancelled`.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks concluem, o macro entra em Verificação.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence próprios do pai.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação global ao abrir o dashboard, em cada turno ou em intervalo automático.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n',j=e(),M=`# ZAIP-AIOS (6 Squads + 23 Agents)
-## Visão rápida
-O ZAIP-AIOS é um sistema operacional para execução autônoma de trabalho com agentes de IA, que coordena 23 agentes especializados, organizados em 6 squads, dentro do Codex.
-Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios definidos ou registrar um bloqueio, falha ou limite de orçamento. Dependências externas e decisões fora da autoridade recebida continuam exigindo intervenção humana; autonomia não significa execução indefinida nem garantia de acerto.
-Essa abordagem busca reduzir intervenções, contexto desnecessário e retrabalho. Os percentuais de 34% e 62% apresentados adiante se referem a custo médio por tarefa e por hora nas séries históricas ilustradas, respectivamente; não medem diretamente redução de tokens nem garantem economia em uma nova entrega.
-Embora tenha nascido com foco em software, o ZAIP-AIOS também coordena demandas de Operações, Growth, Marketing, Branding e Vendas. O framework e o Dashboard funcionam localmente, sem exigir VPS. Autenticação, franquia, cobrança e integrações dependem do host/provider escolhido; usar uma assinatura no Codex não transforma o custo equivalente estimado em cobrança de API.
-<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">
-Na prática, o sistema decompõe demandas complexas, organiza o trabalho, seleciona os agentes mais adequados, coordena dependências, acompanha a execução e verifica a qualidade antes de considerar uma entrega concluída.
-O Dashboard centraliza a operação em uma única visão, reunindo Tasks, SPECs e PRDs, além de dependências, bloqueios, tempo de execução, consumo de tokens, custos, revisões e evidências produzidas ao longo do processo.
-<img src=".agents/config/src/dashboard_pt_1_visao_geral.png" alt="Dashboard ZAIP-AIOS, Visão Geral" width="100%">
-Em uma amostra comparativa de tarefas executadas de forma autônoma, o ZAIP-AIOS apresentou uma redução aproximada de 34% no custo médio por tarefa e 62% no custo médio por hora.
-A comparação considera o ciclo completo de trabalho, planejamento, execução, testes, revisões e documentação —, e os resultados devem ser interpretados dentro dos limites da amostra analisada.
-<img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Análise comparativa: custo médio por hora caiu de R$ 410 para R$ 154" width="900">
-A fonte canônica permanece nos arquivos Git-native do repositório. Requisitos, decisões, implementações e provas podem ser versionados; só passam a estar no histórico remoto após commit e publicação explicitamente autorizada. Segredos e estado privado da máquina ficam fora desse histórico.
-O Dashboard utiliza um banco de dados local, descartável e reconstruível, apenas como camada de consulta e visualização. Nenhuma informação crítica depende exclusivamente dele.
-No ZAIP-AIOS, uma Task não é considerada concluída apenas porque um agente terminou sua execução. Ela só é encerrada quando existem evidências objetivas de que os Critérios de Aceite e os requisitos de qualidade foram atendidos.
-## Comece por aqui
-| Se você quer… | Comece por… |
-| --- | --- |
-| Instalar e obter o primeiro resultado | [Instalação em um comando](#instalação-em-um-comando) |
-| Conhecer os resultados observados | [Economia medida](#economia-medida-e-meta-central-por-tarefa) |
-| Acompanhar trabalho, custos e qualidade | [Dashboard Local](#dashboard-local) |
-| Fazer uma alteração pontual | [Três formas de executar](#três-formas-de-executar) |
-| Planejar uma entrega técnica ou de produto | [PRD como interface de autonomia](#prd-como-interface-de-autonomia) |
-| Entender o método | [Método ZAIP em seis etapas](#método-zaip-em-seis-etapas) |
-| Conhecer os agentes especializados | [Personas e roteamento de agentes](#personas-e-roteamento-de-agentes) |
-| Consultar os contratos técnicos | [Referência técnica e operacional](#referência-técnica-e-operacional) |
-| Manter o framework | [Desenvolvimento do framework](#desenvolvimento-do-framework) |
-| Configurar permissões com segurança | [Segurança com perfis de permissão](#segurança-com-perfis-de-permissão) |
-| Avaliar lançamento, suporte e comercialização | [Prontidão para produção e comercialização](docs/PRODUCTION-COMMERCIAL-READINESS.md) |
-| Navegar pelos 28 guias operacionais | [Índice completo do handbook](.agents/zaip-aios/INDEX.md) |
-### Como interpretar esta documentação
-Este README e o [handbook](.agents/zaip-aios/INDEX.md) descrevem o código-fonte deste repositório. Configuração efetiva, suporte do host, pacote instalado e candidato qualificado são dimensões distintas. \`@latest\` aponta para a versão publicada, que pode não conter alterações locais. As imagens do Dashboard são ilustrações de estados anteriores, não prova visual do candidato atual.
-A atualização documental não aprova uma release. Consulte o [registro de limites de qualificação](docs/PRODUCTION-COMMERCIAL-READINESS.md#limites-conhecidos-da-qualificação) antes de promover o código; testes locais, paridade, CI e validação em produção devem ser comprovados separadamente.
-## Instalação em um comando
-Com Git e uma versão compatível de Node.js, a instalação acontece na raiz do repositório que receberá o ZAIP-AIOS. O pacote declara Node.js 22+; para o Dashboard com \`node:sqlite\`, use uma versão que disponibilize esse módulo (o ambiente de referência deste checkout usa 22.16.0), não qualquer versão inicial da série 22:
-\`\`\`bash
-npx @zaip-ai/cli@latest init
-\`\`\`
-O sufixo \`@latest\` instala a release pública atual sem fixar o README a uma versão específica. O CLI encontra a raiz Git mesmo quando o comando é iniciado em uma subpasta, valida o template antes de escrever e interrompe a instalação se detectar conflito com arquivo pertencente ao usuário. O mesmo comando pode ser executado novamente para receber arquivos novos e atualizar adapters gerenciados sem apagar o histórico do projeto.
-Cada release do CLI leva seu próprio template verificado. A árvore documentada neste README representa o estado atual do repositório-fonte; uma funcionalidade recém-integrada passa a chegar pelo mesmo comando assim que a release correspondente é publicada.
-O instalador cria [\`.agents\`](.agents/) com regras, requisitos, skills, documentação operacional, catálogo de ferramentas, Dashboard, design system e estado Git-native do lifecycle. Também instala os adapters \`AGENTS.md\` e \`CLAUDE.md\`, as skills de descoberta em \`.codex/skills/zaip-aios/SKILL.md\` e \`.claude/skills/zaip-aios/SKILL.md\`, a configuração de projeto \`.codex/config.toml\` e as configurações equivalentes do Claude. Todos apontam para a mesma fonte canônica, preservando o Codex como experiência principal sem acoplar PRDs, SPECs, Tasks e evidências a um único host.
-Depois da instalação, o [índice operacional](.agents/zaip-aios/INDEX.md) organiza os guias de primeiros passos, execução, revisão, custos, ferramentas, diagnóstico e atualização.
-## Como as camadas se complementam
-| Tipo | Nome | Responsabilidade |
-| --- | --- | --- |
-| **Modelo de IA (AI Model)** | **GPT-5.6 (padrão)** | Modelo principal para raciocínio, programação, uso de ferramentas, coordenação de agentes e execução de tarefas complexas. A configuração permanece aberta para testes, comparação ou substituição por outros modelos. |
-| **Ferramenta (AI Harness)** | **Codex (padrão)** | Harness oficial que conecta o modelo LLM ao terminal, ferramentas, subagentes, worktrees, sandbox, hooks, skills e navegador. Por estar alinhado ao treinamento do modelo, oferece maior otimização, previsibilidade e aproveitamento de suas capacidades. |
-| **Metodologia (AI Coding)** | **ZAIP-AIOS** | Sistema Git-native de engenharia autônoma e multiagente. Converte PRDs e SPECs em Tasks, DAGs e Changes executáveis, automatiza testes e reviews e mantém decisões, execuções, evidências, custos e mudanças rastreáveis no Git. |
-O modelo fornece a inteligência, o Codex oferece o ambiente oficial de execução e o ZAIP-AIOS acrescenta método, governança e memória verificável. Essa combinação define **o que deve ser feito, como o trabalho deve ser organizado, quais regras precisam ser respeitadas e quais provas permitem declará-lo concluído**. A experiência de referência é otimizada para GPT-5.6 e Codex, enquanto modelos e hosts alternativos permanecem disponíveis para comparação e compatibilidade por meio de artefatos portáveis.
-## Personas e roteamento de agentes
-O ZAIP-AIOS reúne 23 agentes especializados para que cada demanda seja conduzida pela competência mais adequada. O objetivo não é usar todos em cada entrega, mas formar o menor conjunto capaz de executar, revisar e comprovar o resultado com qualidade.
-As identidades técnicas permanecem separadas das personas visíveis. Assim, nomes e cargos podem ser apresentados e configurados no Dashboard sem comprometer os contratos internos de roteamento. A escolha considera a decisão ou o resultado primário, especialidade, escopo e risco; referências e insumos apoiam o trabalho, mas não mudam sozinhos o executor. Autoria, contexto e histórico permanecem rastreáveis.
-### Os 23 agentes
-| Foto | # | Persona / função | Especialidade |
-| :---: | ---: | --- | --- |
-| <img src=".agents/config/src/1%20-%20Dave%20-%20Product%20Owner.png" alt="Dave, Product Owner" width="400"> | 1 | Dave / Product Owner | Resolve DAG e delega |
-| <img src=".agents/config/src/2%20-%20Rafa%20-%20Tech%20Lead.png" alt="Rafa, Tech Lead" width="400"> | 2 | Rafa / Tech Lead | Entrega genérica, SPEC e dashboard/local |
-| <img src=".agents/config/src/3%20-%20Leo%20-%20Software%20Engineer.png" alt="Leo, Software Engineer" width="400"> | 3 | Leo / Software Engineer | Task genérica ponta a ponta |
-| <img src=".agents/config/src/4%20-%20Bia%20-%20Product%20Manager.png" alt="Bia, Product Manager" width="400"> | 4 | Bia / Product Manager | Criação/refino de PRD e análise de produto |
-| <img src=".agents/config/src/5%20-%20Gui%20-%20Quality%20Assurance%20Lead.png" alt="Gui, Quality Assurance Lead" width="400"> | 5 | Gui / Quality Assurance Lead | Resultado terminal restrito |
-| <img src=".agents/config/src/6%20-%20Nanda%20-%20Principal%20Engineer.png" alt="Nanda, Principal Engineer" width="400"> | 6 | Nanda / Principal Engineer | Revisão independente |
-| <img src=".agents/config/src/7%20-%20Dani%20-%20Integration%20Engineer.png" alt="Dani, Integration Engineer" width="400"> | 7 | Dani / Integration Engineer | Integração e gates combinados |
-| <img src=".agents/config/src/8%20-%20Ana%20-%20Quality%20Auditor.png" alt="Ana, Quality Auditor" width="400"> | 8 | Ana / Quality Auditor | Auditoria independente |
-| <img src=".agents/config/src/9%20-%20Lia%20-%20Technical%20Writer.png" alt="Lia, Technical Writer" width="400"> | 9 | Lia / Technical Writer | Resumo fiel, análise de transcrição e documentação fundamentada em fontes |
-| <img src=".agents/config/src/10%20-%20Gabi%20-%20Data%20Analyst.png" alt="Gabi, Data Analyst" width="400"> | 10 | Gabi / Data Analyst | Análise de dados |
-| <img src=".agents/config/src/11%20-%20Tati%20-%20Refactoring%20Specialist.png" alt="Tati, Refactoring Specialist" width="400"> | 11 | Tati / Refactoring Specialist | Refatoração, migração e modularização seguras |
-| <img src=".agents/config/src/12%20-%20Doug%20-%20Frontend%20Developer.png" alt="Doug, Frontend Developer" width="400"> | 12 | Doug / Frontend Developer | Frontend e acessibilidade conforme \`DESIGN.md\` |
-| <img src=".agents/config/src/13%20-%20Will%20-%20Backend%20Developer.png" alt="Will, Backend Developer" width="400"> | 13 | Will / Backend Developer | API, backend e módulos |
-| <img src=".agents/config/src/14%20-%20Jonny%20-%20Website%20Developer.png" alt="Jonny, Website Developer" width="400"> | 14 | Jonny / Website Developer | Sites e landing pages, SEO, GEO e preparação para agentes |
-| <img src=".agents/config/src/15%20-%20Manu%20-%20Product%20Designer.png" alt="Manu, Product Designer" width="400"> | 15 | Manu / Product Designer | \`DESIGN.md\`, Design System, tokens e catálogo |
-| <img src=".agents/config/src/16%20-%20Dan%20-%20Cloud%20Engineer.png" alt="Dan, Cloud Engineer" width="400"> | 16 | Dan / Cloud Engineer | Infraestrutura cloud, Terraform, Docker e ambientes |
-| <img src=".agents/config/src/17%20-%20Luis%20-%20Security%20Auditor.png" alt="Luiz, Security Auditor" width="400"> | 17 | Luiz / Security Auditor | Auditoria técnica e independente de segurança |
-| <img src=".agents/config/src/18%20-%20Lucia%20-%20Marketing%20Analyst.png" alt="Lucia, Marketing Analyst" width="400"> | 18 | Lucia / Marketing Analyst | Planejamento de marketing, copy e preparação de ativos |
-| <img src=".agents/config/src/19%20-%20Renata%20-%20Compliance%20Specialist.png" alt="Renata, Compliance Specialist" width="400"> | 19 | Renata / Governance & Compliance Specialist | Artefatos internos de RH, jurídico operacional, políticas, privacidade, fornecedores e riscos |
-| <img src=".agents/config/src/20%20-%20Clara%20-%20Operations%20Specialist.png" alt="Clara, Operations Specialist" width="400"> | 20 | Clara / Operations Generalist | Documentos, apresentações, planilhas, processos e comparativos delimitados fora de especialidades obrigatórias |
-| <img src=".agents/config/src/21%20-%20Sarah%20-%20Branding%20Specialist.png" alt="Sarah, Branding Specialist" width="400"> | 21 | Sarah / Branding Specialist | Estratégia e governança de marca, Brandbook, arquétipos, diferencial semântico e arquitetura de marca |
-| <img src=".agents/config/src/22%20-%20Aaron%20-%20Sales%20Specialist.png" alt="Aaron, Sales Specialist" width="400"> | 22 | Aaron / Sales Specialist | Processo comercial interno, qualificação, playbooks, scripts e handoffs entre SDR e closer |
-| <img src=".agents/config/src/23%20-%20Robert%20-%20Growth%20Strategist.png" alt="Robert, Growth Strategist" width="400"> | 23 | Robert / Growth Strategist | Estratégia de crescimento, RevOps, experimentos e recomendações orientadas por dados e impacto financeiro |
-O [Catálogo de agentes](.agents/zaip-aios/guides/18-catalogo-de-agentes.md) reúne as especialidades e responsabilidades dos agentes disponíveis no ZAIP-AIOS.
-### Squads organizacionais
-<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">
-Os seis squads tornam a estrutura de responsabilidades fácil de visualizar: **Product** (Dave, Bia e Manu), **Admin & Operations** (Clara, Renata e Lia), **Development** (Rafa, Leo, Jonny, Will, Doug e Tati), **Delivery Assurance** (Nanda, Gui, Ana e Dani), **Infra & Security** (Dan e Luiz) e **Growth — Sales, Marketing and Branding** (Robert, Gabi, Lucia, Sarah e Aaron).
-Essa é uma visão organizacional, não uma regra de roteamento. O orquestrador seleciona o agente por capability, escopo declarado, risco e write scopes da Task; pertencer ao mesmo squad não concede acesso, não substitui a seleção canônica e não obriga colaboração.
-Cada demanda pode começar como uma Task, uma SPEC ou um PRD. Em qualquer entrada, a intenção é transformada em trabalho estruturado, com objetivo, escopo, critérios de qualidade e etapas rastreáveis.
-O Codex permanece como ambiente de execução, enquanto o ZAIP-AIOS acrescenta organização, governança e visibilidade ao ciclo de desenvolvimento. Pelo Dashboard, é possível acompanhar o avanço das entregas, suas dependências, bloqueios e resultados.
-Quando executado com a conta ChatGPT/Codex, o consumo segue as condições dessa conta. O Dashboard apresenta, quando há telemetria e preço compatível, uma estimativa de custo equivalente de API para comparação e planejamento; outros providers podem ter modalidades próprias de cobrança.
-## Dashboard Local
-O Dashboard transforma o histórico técnico do ZAIP-AIOS em uma visão operacional clara. Em um só lugar, ele mostra o trabalho em andamento, os custos observados, a cobertura de qualidade, os bloqueios e a relação entre intenção, execução e resultado.
-<img src=".agents/config/src/dashboard_pt_1_visao_geral_este_mes.png" alt="Dashboard ZAIP-AIOS, Visao Geral Mes" width="100%">
-Os registros Git-native continuam sendo a fonte oficial. Tudo o que aparece nas telas pode ser reconstruído a partir dos arquivos canônicos e da configuração do projeto, sem criar uma base paralela ou dependência externa de infraestrutura.
-<strong>Como funciona a projeção local do Dashboard</strong>
-Os registros ZAIP canônicos permanecem na estrutura padrão em \`.agents/records\`. Para acelerar consultas e visualizações, o Dashboard reconstrói um SQLite descartável como *read model*. Esse arquivo não é fonte de verdade nem armazenamento canônico: é apenas uma projeção local reconstruível.
-Não é preciso instalar servidor SQLite, DBeaver ou banco externo. O runtime usa \`node:sqlite\` e mantém a projeção em \`.local/dashboard-sqlite/read-model.sqlite\`. Abrir ou atualizar o Dashboard não autoriza reconciliação global de Runs: essa operação é separada e exige confirmação.
-### Kanban
-Organiza PRDs, SPECs e Tasks por estágio, destacando execução, verificação, conclusão, criticidade, tempo, tokens e custo observado.
-<img src=".agents/config/src/dashboard_pt_2_kanban.png" alt="Dashboard ZAIP-AIOS, Kanban" width="100%">
-As visões Trabalho (Kanban) e Trabalho (Lista) permitem alternar entre leitura por estágio e comparação detalhada. Ambas preservam os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas, facilitando a análise de status, origem, risco, Runs, Sub-Runs, tempo, tokens, custo e cobertura. Cada item pode ser aberto para investigar bloqueios e consultar seu histórico rastreável.
-### Monitor de Custos
-Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero.
-<img src=".agents/config/src/dashboard_pt_3_monitor_custos.png" alt="Dashboard ZAIP-AIOS, Monitor de Custos" width="100%">
-O Monitor consolida tokens, tempo, custo e cobertura por Run, Task, SPEC e PRD. Isso permite comparar conversa, planejamento, execução, trabalho novo e rework, além de identificar médias e concentrações de consumo por dia, mês ou ano.
-Quando o Codex utiliza os tokens ou a franquia da conta em vez de cobrar uma API, o módulo calcula, sempre que há medição e pricing compatível, o **custo equivalente estimado de API** em USD e BRL. A estimativa apoia gestão e comparação, mas nunca é apresentada como cobrança real. Valores não observados continuam \`unknown\`, sem serem convertidos artificialmente em zero.
-**Contrato técnico da telemetria**
-A telemetria do Codex usa spool local sanitizado, um \`InvocationSummary\` por invocação e chunks com
-manifestos mensais rastreados pelo Git. Consultas com período usam os manifestos primeiro e mantêm
-fallback para a projeção de Run quando não existe resumo aplicável. Cobertura incompleta continua
-explícita em cada métrica. A [Telemetria Git-native do Codex](.agents/zaip-aios/guides/27-telemetria-git-native.md)
-documenta contratos, armazenamento, integridade, recuperação e limites do rollout.
-### Rastreabilidade
-Relaciona intenção, planejamento, execução, decisões, validações e evidências para explicar de onde cada resultado veio.
-<img src=".agents/config/src/dashboard_pt_4_rastreabilidade.png" alt="Dashboard ZAIP-AIOS, Rastreabilidade" width="100%">
-Correlaciona PRD, Requirements, SPEC, Change, Task, Execution, Runs, Decisions, testes, reviews, evals e Evidence em um grafo lógico de rastreabilidade. A visão detalha as seis etapas do método e mostra quais documentos e provas sustentam cada resultado. Cada registro recebe identificador, data e hora quando faz parte do lifecycle ou da telemetria; as evidências permanecem vinculadas e a cronologia também é preservada pelo Git. Isso permite auditoria, retomada, análise de rework e comparação entre intenção e execução. Projeções podem ser reconstruídas e otimizadas; a compactação Git-native da telemetria preserva IDs, relações, métricas, cobertura e hashes sem versionar prompts ou respostas.
-## Configurações do projeto
-O Dashboard reúne a configuração do projeto em uma tela ligada ao arquivo canônico \`.agents/config/project.yaml\`. Antes de salvar, a configuração é validada pelo schema, preservando uma definição explícita do framework, das capacidades disponíveis e da visão geral dos artefatos do projeto.
-### Configuração da plataforma
-A configuração da plataforma apresenta o estado de ativação do ZAIP-AIOS e um resumo dos agentes, squads, skills, Rules, hooks e banco de dados. A mesma visão mostra os documentos de referência do projeto e indica quais deles já existem, mantendo a configuração técnica e a documentação visíveis no mesmo contexto.
-<img src=".agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="Dashboard ZAIP-AIOS, configuração da plataforma" width="100%">
-### Stack de desenvolvimento
-A stack de desenvolvimento descreve cada responsabilidade separadamente, com tecnologia, versão exata e referência do pacote, imagem ou serviço. No projeto, esse contrato inclui TypeScript, Node.js, Hono, Kysely, PostgreSQL via Supabase, Supabase Auth + Storage, Redis e BullMQ, permitindo que as escolhas de desenvolvimento permaneçam registradas junto da configuração do projeto.
-<img src=".agents/config/src/dashboard_pt_configuracao_plataforma_stack.png" alt="Dashboard ZAIP-AIOS, stack de desenvolvimento" width="100%">
-## O custo que importa: concluir a tarefa
-O preço de uma chamada ou de um modelo não representa sozinho o custo real do desenvolvimento com IA. Uma entrega pode envolver entendimento, leitura de contexto, implementação, testes, correções, revisão, validação e documentação. Por isso, o ZAIP-AIOS mede **o custo para concluir o trabalho**, acompanhando Runs, fases e rework por Task, SPEC e PRD.
-Uma forma prática de analisar o custo total é:
-\`\`\`text
-custo da tarefa concluída = modelo + ferramentas + tempo humano + rework + custo de defeitos
-\`\`\`
-## PRD como interface de autonomia
-O PRD permite governar uma iniciativa completa sem transformar cada decisão técnica em uma nova etapa manual. Ele registra o resultado esperado, organiza as entregas necessárias e mantém espaço para revisão humana antes da execução.
-Quando o usuário diz **“Me ajude a pensar sobre um PRD”**, o sistema mantém a interação como uma conversa de planejamento.
-Quando diz **“Crie um PRD”**, a IA faz até cinco perguntas importantes por turno, por no máximo três turnos. Depois, cria:
-- um PRD em estado \`draft\`
-- as SPECs técnicas necessárias
-- um \`PreparedPlan\`
-- uma lista resumida de Tasks
-As decisões técnicas que puderem ser delegadas são assumidas e registradas pela IA.
-**Detalhes de planejamento, decomposição e comandos**
-### Organização das SPECs
-Por padrão, cada PRD utiliza apenas uma SPEC, buscando economia.
-Uma nova SPEC só deve ser criada quando existir uma capacidade que possa ser implementada e validada de forma independente e paralela. Quando existe dependência entre partes do trabalho, elas permanecem na mesma SPEC e são organizadas pela DAG de Tasks.
-No runtime atual, um PRD materializa uma Execution-filho determinística para cada SPEC elegível: suas dependências permanecem dentro da SPEC e seus write scopes não conflitam com nenhum outro ramo. Cada filha executa com coordinator, estado, quota de orçamento e handoff próprios, sob uma fila limitada pelo paralelismo efetivo e por um ledger parental único de invocações; a Execution do PRD aguarda os estados terminais, integra os candidatos no handoff parental e só então aplica validação cross-SPEC e finalização. SPECs com dependência externa ou conflito de escopo permanecem na DAG global coordenadora.
-Antes de o PRD chegar ao estado \`ready\`, as Tasks são apenas definições de trabalho, ainda sem execução.
-Os comandos **“Deixe pronto para executar”**, **“Finalize o PRD”** ou **“Conclua o PRD”** criam as Tasks, Changes e Executions no estado \`planned\`, mas não iniciam a implementação.
-O comando **“Execute”** atua sobre o menor item informado pelo usuário, que pode ser uma Task, uma SPEC ou o PRD completo.
-### Limite de decomposição
-A escala de 1 a 5 define o limite de decomposição do PRD. Ela não representa uma meta obrigatória.
-* Nível 1 cobre um único fluxo vertical
-* Níveis 2 a 4 exigem capacidades independentes, com contratos e escopos de escrita separados
-* Nível 5 deve ser usado apenas em casos excepcionais com cinco implementações semelhantes e independentes
-Quando existe dependência entre capacidades, o trabalho deve permanecer na mesma SPEC. Projetos com mais de cinco capacidades devem ser divididos em outros PRDs ou registrar uma exceção.
-### Comportamento dos comandos
-O comando \`implemente\` considera o estado atual do trabalho:
-* sem alvo definido, abre uma Conversation de planejamento
-* em \`draft\`, conclui o plano
-* em \`ready\`, inicia a execução
-* em estados ativos ou com falha, continua, retoma ou inicia o rework
-Os comandos \`desenvolva\`, \`melhore\` e \`aprimore\` sempre retornam ao planejamento ou ao rework.
-Um PRD cancelado não pode ser alterado. Quando necessário, um novo PRD de rework é criado, preservando o vínculo e o histórico de auditoria.
-### Rastreamento de execução
-Toda criação de PRD ou SPEC é vinculada à Run responsável por meio do campo \`creation_run_id\`.
-Tempo, tokens e custo são agregados sempre que essas informações estiverem disponíveis ou forem reconciliadas. Quando não houver dados suficientes, os valores permanecem como \`unknown\` ou \`null\`.
-## Qualidade e evidências
-Qualidade faz parte da definição de pronto. Cada entrega combina testes, revisão e checks proporcionais ao seu risco, com comprovação objetiva dos Critérios de Aceite.
-As Evidence conectam validações aprovadas à Task, Change, Execution, Run, Critérios de Aceite e candidato. O [guia de revisão](.agents/zaip-aios/guides/07-revisao-e-validacao.md) explica como registrar o procedimento realmente executado e seu resultado.
-O contrato atual acrescenta observações \`confirmed\`, \`limited\`, \`pending\`, \`failed\` e \`not_applicable\`, sem substituir Validation/Evidence V2. A CLI valida estrutura e vínculos; não executa o comando declarado, não examina imagens e não consulta serviços automaticamente. Prova técnica não equivale a prova visual, integração real ou produção. Observações isoladas ou pendentes não aprovam uma entrega.
-Novos registros de Validation, Evidence, Observation e eventos de Run rejeitam padrões conhecidos de credenciais antes da persistência, sem repetir o valor sensível no erro. Use locators e resultados sanitizados; a proteção não certifica que um texto está livre de todo segredo ou dado pessoal. Históricos continuam legíveis e não são reescritos automaticamente.
-Para reduzir ciclos sem reduzir qualidade, escolha cedo o cenário que pode revelar uma direção errada. Repita após uma mudança concreta ou resultado que exija correção, não apenas porque o relógio avançou. A indisponibilidade da mesma ferramenta tem fallback finito e pendência explícita; a suficiência da prova continua sendo responsabilidade do executor/revisor. Consulte o [contrato canônico de prova observável](.agents/skills/zaip-skill-change/references/observable-evidence.md).
-Tests, reviews, checks e Evidence tornam a evolução do projeto mais previsível: elevam a confiança nas mudanças, facilitam revisões e mantêm decisões, validações e aprimoramentos plenamente rastreáveis.
-## Economia medida e meta central por tarefa
-As análises abaixo apresentam reduções de custo **medidas na amostra comparativa** sob duas perspectivas complementares: custo médio por Task e custo médio por hora. Os gráficos e a tabela detalham os valores, os cálculos e a leitura de cada indicador. Os resultados confirmam redução nas séries analisadas, mas não devem ser generalizados para toda Task, modelo ou repositório sem uma nova comparação equivalente.
-### Análise de custo por tarefa
-Este gráfico acompanha o custo de cada Task nas duas faixas comparadas. A média inicial é de **R$ 67 por tarefa**; no recorte posterior, ela passa a **R$ 44**. A redução de **34,3%** (apresentada como aproximadamente 34%) representa o custo médio menor para concluir uma unidade de trabalho na amostra observada.
-<img src=".agents/config/src/analise_comparativa_reducao_custo_por_tarefa.png" alt="Análise comparativa: custo médio por tarefa caiu de R$ 67 para R$ 44" width="900">
-### Análise de custo por hora
-Este gráfico apresenta a mesma comparação na perspectiva horária. A média de custo cai de **R$ 410 por hora** para **R$ 154 por hora**, uma redução de **62,4%** (aproximadamente 62%). Essa leitura complementa a análise por Task ao mostrar que a redução também se mantém quando o custo é observado por hora.
-<img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Análise comparativa: custo médio por hora caiu de R$ 410 para R$ 154" width="900">
-Cada indicador abaixo mede uma parte diferente do fluxo. Os percentuais não devem ser somados, pois podem refletir otimizações simultâneas na mesma execução. As métricas de contexto e payload continuam sendo medições reproduzíveis do snapshot de **18/08/2026**; elas não descrevem automaticamente a população atual de skills ou do repositório.
-As duas primeiras linhas são resultados financeiros observados nas séries comparativas. As demais isolam ganhos de payload e navegação que ajudam a explicar como o fluxo pode reduzir custo, ciclos e retrabalho.
-| O que é reduzido | O que representa | Baseline sem a otimização | Com ZAIP-AIOS | Economia | Situação da métrica |
-| --- | --- | ---: | ---: | ---: | --- |
-| **Custo médio por tarefa** | Média de custo das Tasks nas duas faixas da série comparativa. | **R$ 67** | **R$ 44** | **34%** | **Medição observada** na comparação apresentada (redução exata: 34,3%). |
-| **Custo médio por hora** | Média de custo por hora nas duas faixas da série comparativa. | **R$ 410** | **R$ 154** | **62%** | **Medição observada** na comparação apresentada (redução exata: 62,4%). |
-| **Contexto entregue ao agente para uma Task** | O pack de Rules, Requirements e artefatos relevantes que entra no prompt de trabalho. | 7.980 tokens | **1.593 tokens** | **80,0%** | Medição reproduzível. |
-| **Navegação operacional recorrente** | Uma rodada de quatro consultas para localizar Changes, Tasks, Executions e Runs ativos. | 101.924 tokens | **10.199 tokens** | **90,0%** | Medição reproduzível; também reduz o limite de paginação. |
-| **Instruções disponíveis para o agente** | Snapshot de 13/07/2026 do catálogo então consultável pelo agente (26 skills). | 1.091 tokens | **599 tokens** | **45,1%** | Medição reproduzível do snapshot; não é a contagem atual de skills. |
-### Metodologia da comparação
-A comprovação de economia baseia-se em coortes de Tasks equivalentes, observadas em dois cenários — por exemplo, Codex normal e Codex + ZAIP-AIOS — com o mesmo modelo, repositório, Critérios de Aceite e janela de observação. Essa equivalência mantém a comparação centrada no efeito do fluxo de trabalho.
-Os indicadores que compõem a análise são:
-- tokens e custo equivalente de API de todas as chamadas até a conclusão;
-- duração e número de ciclos/retries;
-- tempo humano de revisão e correção;
-- taxa de rework e defeitos encontrados após a entrega;
-- cobertura de testes, reviews e evidências dos Critérios de Aceite.
-O Cost Monitor preserva valores desconhecidos como \`unknown\`/\`null\` e não converte ausência de telemetria em custo zero. Dessa forma, os resultados mantêm visíveis custos de provider, rework ou qualidade que ainda não tenham sido observados. A metodologia e seus registros complementares estão em [a auditoria de tokens e performance](analysis/verificacao-auditoria-tokens-performance-zaip-aios-2026-07-13.md).
-O comando \`zaip cost cohort --input <arquivo.json> --json\` calcula coortes comparáveis a partir de custos faturados observados e sua proveniência. O contrato de cálculo exige moeda USD, fonte, timestamp, *quality floor*, tentativa terminal e uma única identidade de baseline equivalente. Na ausência ou divergência de uma dimensão obrigatória, a economia permanece \`null\`, preservando a integridade da comparação.
-## Comparação com os principais frameworks concorrentes
-Esta seção preserva um recorte histórico, não uma pesquisa de mercado atualizada nem certificação de produção. As notas abaixo não substituem a qualificação do candidato atual e não foram recalculadas nesta revisão documental.
-Este recorte usa uma auditoria comparativa, consolidada em 6 de agosto de 2026, e posiciona cada produto a partir dos sinais encontrados em código, configuração, arquitetura, testes e documentação. A metodologia reúne dez critérios com o mesmo peso: cada tópico recebe de 0 a 10 pontos e a nota final, de 0 a 100, é a soma direta desses resultados. Na escala adotada, 9–10 indica uma referência clara no critério; 7–8, uma proposta forte e competitiva; 5–6, uma capacidade relevante ainda parcial; e 0–4, pouca evidência ou baixa ênfase no recorte analisado. A matriz detalhada torna a composição das notas transparente e permite atualizá-las conforme os produtos evoluem.
-| Produto | Nota /100 | Justificativa da nota | Posicionamento competitivo |
-|---|---:|---|---|
-| ZAIP-AIOS | **95** | Lidera tecnicamente neste recorte local ao unir SDD, arquitetura limpa e qualidade baseada em Evidence com orquestração multiagente, segurança, contexto e observabilidade financeira por Task no mesmo lifecycle auditável. | Plataforma completa para engenharia de software com agentes, reunindo especificação, execução, validação, segurança e observabilidade em um lifecycle rastreável. |
-| Traycer | 83 | Coding agents conectados, loops agente–agente para arquitetura/review, CLI/terminal e worktrees são fortes; custo por Task e execução do host assinado não foram reproduzidos. | Mais especializado que OpenClaw para orquestrar coding agents, sem substituir validação de produto. |
-| AIOX Core | 82 | Spec pipeline, dev/QA, worktrees, recovery, memória e integrações Codex/Cursor/Claude sustentam o fluxo; hooks têm paridade desigual e não há custo por Task. | Plataforma de desenvolvimento ampla, com DX forte mas menos direta que Traycer. |
-| Kilo Code | 80 | Agente de código para VS Code, JetBrains e CLI, com Debug, Review, autocorreção e \`kilo run --auto\`; telemetria existe, mas custo por Task não foi comprovado. | DX de programação first-class, com limites de evidência em isolamento e recovery. |
-| TLC Spec-Driven | 80 | Skill SDD adaptativo com AC→teste, matriz de cobertura, verifier independente, sensor de discriminação e lessons locais; o contrato é forte, mas o enforcement depende de agente/host. | Muito forte em rastreabilidade e verificação; benchmark autorreferenciado sem bruto e sem telemetria/custo por Task. |
-| Roo Code | 79 | VS Code com modos Code, Architect e Debug, refactor, histórico/resume e worktrees; não há custo consolidado por Task. | Encaixe editor-first muito forte, com governança operacional parcial. |
-| Superpowers | 78 | Skills de TDD, worktrees, subagentes, review e debugging tornam o playbook de programação consistente; suas garantias continuam instrucionais e os testes comportamentais dependem de repositório externo. | Forte disciplina para coding agents, sem lifecycle tipado nem custo por Task. |
-| OpenClaw | 73 | Subagentes Codex-native, sessões isoladas, sandbox e testes são fortes, mas o gateway assistente multicanal não demonstra o mesmo fluxo coding-first de IDE/CLI. | Referência em isolamento e operação geral; fica abaixo de Traycer, Kilo e Roo no recorte de programação. |
-| Hermes | 71 | Retry, memória e usage/pricing sustentam recursos de coding, mas a plataforma é generalista e não coding-first; custo por Task não está demonstrado. | Produto autônomo amplo, não equivalente automaticamente a um agente de desenvolvimento especializado. |
-| OpenSpec | 70 | Delta specs, schemas, CLI, workspaces e testes estruturam a evolução de mudanças; a verificação é opcional/parcialmente heurística. | Especialista em gestão de specs, não runtime multiagente, sem custo por Task. |
-| OpenCode  | 60 | TUI/CLI, edição/patch, comandos, LSP, MCP/providers, permissões e sessões SQLite compõem uma base enxuta e extensível para programação no terminal. | Alternativa direta para desenvolvimento no terminal, com oportunidades de ampliar multiagentes, lifecycle, testes e custo por Task. |
-**Consultar a matriz técnica dos dez critérios**
-| Tópico (0–10) | ZAIP | OpenClaw | Traycer | Kilo | Hermes | AIOX | Roo Code | OpenCode | TLC Spec-Driven | Superpowers | OpenSpec |
-|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
-| T1 — SDD e rastreabilidade | 10 | 6 | 7 | 6 | 6 | 9 | 6 | 3 | 9 | 8 | 9 |
-| T2 — Loop planejar–editar–testar–corrigir | 9 | 7 | 9 | 10 | 7 | 9 | 9 | 8 | 9 | 9 | 6 |
-| T3 — Multiagentes e isolamento | 10 | 9 | 9 | 8 | 7 | 9 | 8 | 4 | 8 | 9 | 5 |
-| T4 — Arquitetura e repositório | 10 | 8 | 9 | 8 | 7 | 8 | 8 | 8 | 7 | 7 | 8 |
-| T5 — Testes, review e evidência | 10 | 9 | 9 | 9 | 8 | 9 | 9 | 5 | 9 | 9 | 8 |
-| T6 — Recovery e idempotência | 10 | 7 | 9 | 7 | 7 | 8 | 7 | 6 | 8 | 8 | 7 |
-| T7 — Supply chain | 9 | 8 | 8 | 8 | 8 | 7 | 8 | 6 | 7 | 7 | 6 |
-| T8 — Memória de codebase | 9 | 8 | 9 | 8 | 9 | 9 | 8 | 7 | 9 | 8 | 8 |
-| T9 — Telemetria/custo por tarefa de programação | 9 | 6 | 5 | 6 | 6 | 6 | 6 | 4 | 5 | 4 | 4 |
-| T10 — DX CLI/IDE, debug, review, setup e Codex-first | 9 | 5 | 9 | 10 | 6 | 8 | 10 | 9 | 9 | 9 | 9 |
-## Da conversa ao trabalho executável
-O framework ZAIP-AIOS transforma linguagem natural em engenharia estruturada. O usuário pode enviar uma mensagem curta, manter uma conversa de refinamento ou fornecer a transcrição de um áudio longo explicando contexto, restrições e resultado desejado. O framework avalia complexidade, dependências, amplitude e risco para propor a entrada adequada: uma Task para trabalho direto, uma SPEC para uma entrega técnica com múltiplas Tasks ou um PRD para uma iniciativa de produto composta por uma ou mais SPECs. A criticidade \`leve\`, \`padrão\` ou \`crítica\` determina a profundidade de planejamento, revisão, segurança e evidência exigida; nenhum artefato fica fechado à revisão humana.
-Isso permite sair de uma conversa livre sem cair em *vibe coding*: perguntas e análises read-only permanecem Conversations sem Task; pedidos de ação tornam-se trabalho executável. Antes da mutação, a intenção é convertida em requisitos, critérios de aceite, escopo, dependências e write scopes, e uma Task com Run raiz de orquestração entra em Execução. Consulte [Lifecycle de Conversations, Tasks, SPECs e PRDs](.agents/zaip-aios/guides/28-lifecycle-completo.md).
-## Método ZAIP em seis etapas
-| Etapa | Artefatos | O que acontece |
-| --- | --- | --- |
-| **1. Definição** | PRD + Requirements | Registra objetivo, contexto, público, restrições, resultado esperado e Critérios de Aceite que definem o trabalho. |
-| **2. Planejamento** | SPEC + Changes | Descreve escopo, solução, arquitetura, riscos e mudanças previstas antes da execução, seguindo SDD. |
-| **3. Execução** | Tasks + DAG + Executions + Runs | Coordena Tasks, dependências, agentes e arquivos produzidos; registra cada tentativa e seu consumo observável. |
-| **4. Decisões** | Decisions (Human + AI / Planning + Execution) | Preserva decisões humanas e da IA tomadas durante planejamento, execução, revisão e reparo, com contexto e consequências. |
-| **5. Verificação** | Tests + Reviews + Evals + Checks | Executa os mecanismos de qualidade e compara o resultado observado com os requisitos e Critérios de Aceite. |
-| **6. Evidências** | Evidence + Results + Traceability | Coleta, registra e relaciona as provas produzidas pela verificação às Tasks, Changes, Runs e aos Critérios de Aceite; o trabalho só é concluído quando as evidências são suficientes e reproduzíveis. |
-O método mantém intenção e execução separadas. PRD e SPEC explicam o que se pretende entregar; Change, Task, Execution e Run registram como o trabalho foi realizado; Decisions explicam por que caminhos relevantes foram escolhidos; a Verificação executa testes, reviews, evals e checks; e Evidence preserva os resultados observados e sua relação com os Critérios de Aceite. Assim, “concluído” é um estado demonstrado por diff, resultado e evidência reproduzível, não apenas declarado por um agente.
-## Cadeia completa de execução
-Os conceitos abaixo formam o vocabulário técnico usado para ligar intenção, planejamento, execução e prova sem perder o histórico.
-**Consultar o glossário completo do lifecycle**
-| Conceito | Responsabilidade |
-| --- | --- |
-| **Rule** | Regra durável de comportamento, arquitetura, segurança, contexto ou qualidade que o Codex deve seguir. |
-| **Requirement** | Obrigação verificável do produto, acompanhada de Critérios de Aceite. |
-| **PRD** | Documento de Requisitos do Produto que governa uma iniciativa e organiza uma ou mais SPECs. |
-| **SPEC** | Especificação técnica SDD que detalha solução, escopo, riscos, Changes, Tasks e DAG. |
-| **Change** | Narrativa viva de uma mudança planejada e executada: decisões, arquivos afetados, desvios, testes, evidências, rollout, rollback e resultado. |
-| **Task** | Menor unidade executável, com objetivo, risco, prioridade, dependências, write scopes e critérios de aceite. |
-| **DAG** | Grafo acíclico que ordena dependências, identifica paralelismo seguro e impede execução fora da sequência necessária. |
-| **Execution** | Unidade de interação ou entrega, correlacionada ao turno observável: \`interaction\` registra conversa/definição; \`delivery\` coordena trabalho materializado. A idempotência depende da identidade observada do turno; continuação pode reutilizar a delivery vigente. |
-| **Run / Sub-Run** | Run de captura ou do agente orquestrador possui \`parent_run_id: null\`; Sub-Run é cada chamada de subagente relacionada por \`parent_run_id\`. Novos registros usam \`run_role: intake|orchestrator|subagent\`; cada chamada fixa modelo e effort e agrega suas Calls internas. |
-| **Decision** | Decisão humana ou da IA com contexto, alternativa escolhida, motivo, consequências e possibilidade de rollback. |
-| **Evidence** | Prova associada à Task e aos Critérios de Aceite: teste, diff, review, check, relatório ou resultado reproduzível. |
-| **Eval** | Avaliação determinística ou orientada por rubrica que mede qualidade, regressão, aderência e performance. |
-## Três formas de executar
-1. **Task-first:** executa uma única Task independente para mudanças diretas e bem delimitadas.
-2. **SPEC:** executa um conjunto de Tasks relacionadas, coordenadas por uma DAG e governadas pela mesma especificação técnica.
-3. **PRD:** executa uma iniciativa completa, selecionando uma ou mais SPECs, cada uma com suas Changes, Tasks e dependências.
-Essa progressão permite começar de forma simples e acrescentar planejamento apenas quando a amplitude, as dependências ou o risco justificarem uma estrutura maior.
-**Políticas técnicas de execução e assurance**
-Conversation e Task-first preservam a seleção manual do host; o default do projeto não é aplicado automaticamente a uma Task avulsa. A política automática aceita origens SPEC/PRD configuradas em \`automatic_sources\`, com velocidade \`standard\`. Modelo e effort ficam fixos em cada Run/Sub-Run; capacidade ou velocidade indisponível no host não pode ser presumida pelo ZAIP. Consulte a [política de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).
-O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. Toda delivery e interaction com descendentes exigem executor elegível e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. 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](.agents/zaip-aios/guides/19-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.
-O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout optou por \`autonomous\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.
-- **Clean Architecture:** domínio, aplicação, adapters e infraestrutura permanecem separados; regras de negócio não dependem de frameworks ou detalhes externos, as dependências apontam para as camadas internas e composition roots conectam implementações concretas nas bordas.
-- **CQRS:** commands e queries seguem fluxos explícitos e independentes; comandos alteram estado por casos de uso e ports apropriados, enquanto consultas não produzem efeitos colaterais e retornam read models adequados à leitura.
-- **Modularização e organização do código:** pastas, arquivos, módulos e componentes são estruturados por domínio e responsabilidade, com fronteiras explícitas, alta coesão e baixo acoplamento para facilitar navegação, manutenção, testes e evolução do software.
-- **Autonomia dentro de limites:** subagentes trabalham com DAG, write scopes, sandbox, approvals, budgets, regras de segurança e gates proporcionais ao risco.
-- **Contexto progressivo:** cada agente recebe apenas Rules, Requirements, skills e evidências relevantes para seu papel, reduzindo ruído, custo e perda de contexto.
-- **Conclusão baseada em prova:** testes, review, evals, checks e Evidence precisam cobrir os Critérios de Aceite antes da entrega.
-- **Histórico recuperável:** decisões, mudanças, tentativas, falhas, retries, reparos e rollback permanecem vinculados, permitindo pausar, retomar e auditar o trabalho.
-- **Observabilidade honesta:** tokens, custo, tempo, cobertura e performance são medidos por escopo; ausência de telemetria permanece explícita em vez de gerar precisão fictícia.
-O intake captura uma vez por turno observável e reutiliza o foco válido em continuações; publicação puramente Git não cria lifecycle. Perguntas, feedbacks e análises read-only usam Execution \`interaction\`, sem Task ou Change artificial. A criação/refino explícito de PRD/SPEC \`draft\` pode persistir esses macros e o PreparedPlan em interaction, sem delivery. Fora dessa exceção, uma edição avulsa independente materializa e inicia Task, Change, delivery e Run antes da primeira mutação; preparação explicitamente solicitada pode parar em Pronto para Executar. PRD \`draft\` ocupa Definição e SPEC \`draft\` ocupa Planejamento; Tasks nunca ocupam essas colunas.
-## Graph Engineering e Loop Engineering
-<img src=".agents/config/src/zaip-aios-obsidian.png" alt="Zaip AIOS no Obsidian" width="100%">
-O **Graph Engineering** transforma uma entrega complexa em uma sequência coordenada de responsabilidades. Em vez de acionar todos os 23 agentes, a orquestração escolhe o menor conjunto capaz de planejar, executar, revisar e comprovar o resultado conforme dependências, risco e especialidade.
-Essa autonomia permanece governada: Dave coordena, cada executor recebe apenas o escopo necessário, Nanda realiza a revisão independente, especialistas adicionais entram quando existem sinais objetivos e Gui encerra o fluxo por último. O resultado é uma equipe ajustada à demanda, sem multiplicar agentes e custo sem necessidade.
-O **Loop Engineering** orienta o que acontece quando a primeira tentativa não satisfaz os critérios de qualidade. A falha ou o bloqueio é classificado, o próximo ciclo recebe uma configuração proporcional à dificuldade observada e cada tentativa permanece auditável. Em execuções originadas de PRD ou SPEC, o sistema pode evoluir de **Luna → Terra → Sol** e de **low → medium → high → xhigh**; Conversations e Tasks avulsas preservam a seleção manual do host/Codex. O modelo nunca muda silenciosamente dentro da mesma Run.
-### Fluxo resumido
-Um fluxo de entrega com revisão independente é **entrada → Dave → executor por capacidade → Nanda (review) → Gui (finalização)**. A revisão deve atender ao perfil de assurance; não é obrigatório expandir todo trabalho para o mesmo conjunto de agentes. Todos os filhos são coordenados pela orquestração; a sequência não significa que um trabalhador chama o próximo.
-Os cenários completos ficam no [guia de fluxos e roteamento](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md), em texto estável para o GitHub.
-### Fluxos resumidos
-O lifecycle segue **Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído**. Bloqueado, Falhado e Cancelado são saídas alternativas.
-Task, SPEC e PRD mantêm fluxos independentes; Conversation usa uma Execution interaction e não cria Task artificial. A Task direta inicia imediatamente, enquanto a preparada aguarda execute.
-![Lifecycles de Task, SPEC e PRD](.agents/zaip-aios/guides/assets/diagrams/lifecycles-task-spec-prd.png)
-Os fluxos detalhados de roteamento, entrada, planejamento, rework, demanda crítica, seleção de modelo, os 23 agentes e orquestração de Task estão no [guia de fluxos e roteamento](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md).
-## Referência técnica e operacional
-As seções seguintes preservam os contratos necessários para instalação avançada, manutenção, auditoria, segurança e evolução do framework. Elas complementam a visão comercial sem substituir os guias especializados vinculados ao longo do documento.
-## Estrutura atual de \`.agents\`
-**Consultar a árvore de diretórios e as responsabilidades técnicas**
-\`\`\`text
-.agents/
-├── config/
-│   ├── project.yaml
-│   ├── framework.lock.yaml
-│   ├── agents/catalog.yaml
-│   └── profiles/clients.yaml
-├── dashboard/
-│   ├── zaip-dashboard-windows.exe
-│   ├── zaip-dashboard-linux.sh
-│   ├── zaip-dashboard-mac.command
-│   ├── apps/frontend/
-│   ├── modules/{operations,cost-monitor,traceability}/
-│   ├── packages/
-│   └── tests/e2e/
-├── design/
-│   ├── DESIGN.md
-│   ├── tokens.json
-│   ├── zaip-design.exe
-│   ├── apps/catalog/
-│   └── packages/
-├── branding/                         # artefatos de negócio, criada sob demanda
-├── marketing/                        # artefatos de negócio, criada sob demanda
-├── sales/                            # artefatos de negócio, criada sob demanda
-├── growth/                           # artefatos de negócio, criada sob demanda
-├── records/
-│   ├── prds/<ano>/<mês>/
-│   ├── specs/<ano>/<mês>/
-│   ├── changes/<ano>/<mês>/
-│   ├── tasks/<ano>/<mês>/
-│   ├── executions/<ano>/<mês>/
-│   ├── runs/<ano>/<mês>/
-│   ├── lifecycle/                    # manifests, índices e projeções
-│   └── telemetry/<ano>/<mês>/writers/<writer-id>/{manifest.json,chunks/}
-├── rules/
-│   ├── core.md
-│   ├── workflow.md
-│   └── *.md                          # Rules gerenciadas e locais, layout plano
-├── requirements/
-├── skills/
-├── tools/
-│   ├── catalog.yaml
-│   ├── {mcp,api}/
-│   ├── policies/
-│   ├── profiles/
-│   ├── runtime/
-│   └── servers/
-├── zaip-aios/
-│   ├── INDEX.md
-│   └── guides/
-├── runtime/
-│   └── bin/zaip.mjs                  # CLI instalado e metadados de distribuição
-├── .env.example
-└── .gitignore
-.local/                              # na raiz do workspace; ignorado pelo Git
-├── claims/                          # claims atômicos de lifecycle
-├── codex-telemetry-spool/v1/          # captura sanitizada, privada e recuperável
-└── dashboard-sqlite/                 # read model descartável
-\`\`\`
-As pastas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` são áreas de artefatos de negócio criadas sob demanda. A existência e o conteúdo variam por projeto; não é necessário criar pastas vazias.
-| Caminho | Responsabilidade |
-| --- | --- |
-| \`config/\` | Configuração do projeto, perfis de clientes e agentes, maturidade de capacidades e lock de integridade dos arquivos gerenciados. |
-| \`dashboard/\` | Dashboard operacional local com Kanban, custos, tempo, tokens e rastreabilidade; consulta projeções reconstruíveis dos registros canônicos, incluindo SQLite. |
-| \`design/\` | Design system do ZAIP, tokens visuais, catálogo de componentes e launcher local de inspeção. |
-| \`branding/\` | Artefatos de negócio de branding, como Brandbook, plataforma de marca e governança de identidade; é criada sob demanda. |
-| \`marketing/\` | Artefatos de negócio de estratégia, campanhas, conteúdo e ativos de marketing; é criada sob demanda. |
-| \`sales/\` | Artefatos de negócio de metodologia comercial, qualificação, playbooks, scripts e handoffs; é criada sob demanda. |
-| \`growth/\` | Artefatos de negócio de estratégia de crescimento, RevOps e experimentos; é criada sob demanda. |
-| \`records/\` | Fonte canônica Git-native de PRDs, SPECs, Changes, Tasks, Executions e Runs. \`records/lifecycle\` contém manifests, índices, chunks e resumos para descoberta e paginação sem varrer o histórico. |
-| \`requirements/\` | Requisitos duráveis e Critérios de Aceite de lifecycle, execução, custos, contexto, dashboard, arquitetura e design system. |
-| \`rules/\` | Rules canônicas do framework e Rules locais do projeto, todas diretamente neste diretório. |
-| \`skills/\` | Workflows reutilizáveis que transformam conversas em Requirements, Tasks, SPECs e PRDs e orientam execução, revisão, segurança, custos, contexto e ferramentas. |
-| \`tools/\` | Catálogo de MCPs e APIs, políticas de aprovação e segredos, perfis de ativação, doctors e servidores locais gerados de maneira auditável. |
-| \`zaip-aios/\` | Handbook operacional com índice de baixo custo de contexto e guias de instalação, execução, revisão, agentes, custos, segurança e integração com Codex. |
-| \`../.local/\` | Diretório na raiz do workspace com claims, writer ID, spool sanitizado e SQLite descartável; fica fora do Git. O Dashboard consulta a projeção, mas os registros canônicos permanecem em \`records/\`. |
-\`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 está em \`packages/local-runtime\`, não em \`apps/backend\`. Os módulos \`operations\`, \`cost-monitor\` e \`traceability\` consomem read models derivados, com consultas SQLite no runtime atual e caminhos de compatibilidade em memória. A API é predominantemente de leitura, com endpoints controlados para ações como configuração, prioridade, refresh e reconciliação explícita; isso não é permissão para alterações arbitrárias. Os launchers Windows, Linux e macOS ficam diretamente em \`.agents/dashboard\`; sua presença no template não comprova execução nos três ambientes.
-## Arquitetura das aplicações
-**Consultar layout, dependências e limites de código**
-Quando essas superfícies existirem, a estrutura canônica é:
-\`\`\`text
-apps/
-├── frontend/       # UI do produto e composition root do cliente
-├── backend/        # APIs, workers e composition roots de servidor
-└── site/           # landing page e site público, implantável separadamente
-modules/<area>/     # capacidades de negócio e seus contratos públicos
-packages/<library>/ # bibliotecas técnicas reutilizáveis
-tests/e2e/          # fluxos que atravessam aplicações
-\`\`\`
-A direção de dependência é \`apps -> modules -> packages\`. Esta arquitetura descreve exclusivamente o código das aplicações do produto consumidor, não o dashboard ZAIP nem os domínios de negócio. As áreas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` ficam em \`.agents\` como pastas de artefatos de negócio criadas sob demanda; elas não são pastas de aplicação. \`apps/site\` nunca importa o dashboard, não lê \`.agents\` e não depende de implementação privada do backend. Pastas de superfícies ausentes não precisam ser criadas vazias. Testes unitários ficam junto do código; jornadas cross-app ficam em \`tests/e2e\`.
-Arquivos-fonte com 401–800 linhas geram warning e arquivos com 801 ou mais linhas geram erro, salvo exceções explícitas. O gate ignora código gerado, distribuição, vendor, dados e lockfiles. A lista em [source-size-baseline.json](scripts/source-size-baseline.json) inclui legado de pacotes e Dashboard, com limite congelado, responsável, motivo e validade; isso não autoriza aumentar os limites para ocultar crescimento.
-## Desenvolvimento do framework
-**Consultar contratos para mantenedores e contribuidores**
-Esta seção é destinada a mantenedores e contribuidores que alteram o código-fonte do próprio ZAIP-AIOS. Quem apenas instalou o framework dentro de outro repositório não precisa executar esta rotina para usar o Codex, criar Tasks, SPECs ou PRDs, acompanhar o dashboard ou executar o lifecycle normalmente.
-### Repositório-fonte e projeto consumidor
-- **Repositório-fonte:** contém a implementação oficial do ZAIP-AIOS, seus pacotes, dashboard, Rules, Requirements, skills, ferramentas e artefatos de distribuição. Mudanças intencionais nesses componentes precisam passar pelos gates de integridade, qualidade, testes e build.
-- **Projeto consumidor:** recebe uma versão publicada do framework dentro de \`.agents\`. O arquivo \`framework.lock.yaml\` é atualizado somente pelos fluxos transacionais de instalação ou upgrade do CLI; o projeto consumidor não executa \`sync:framework-lock\` para aceitar alterações locais.
-Configurações do projeto consumidor permanecem em \`.agents/config/project.yaml\`; Rules adicionais ficam diretamente em \`.agents/rules/*.md\` e não entram no lock do framework. Arquivos administrados pela distribuição não devem ser modificados e depois incorporados ao lock apenas para silenciar uma divergência.
-### Integridade dos arquivos gerenciados
-O \`framework.lock.yaml\` é um manifesto mecânico de integridade, não um lock de dependências como \`pnpm-lock.yaml\`. Ele registra os caminhos e hashes SHA-256 dos arquivos que pertencem à distribuição do ZAIP-AIOS, permitindo detectar alteração acidental, arquivo ausente ou conteúdo diferente do release esperado. Ele não armazena segredos, telemetria ou histórico de execução.
-Quando um mantenedor altera intencionalmente Rules, Requirements, skills ou outro arquivo gerenciado no repositório-fonte, deve revisar a mudança e então regenerar os hashes:
-\`\`\`bash
-pnpm sync:framework-lock
-pnpm validate:framework-lock
-\`\`\`
-\`sync:framework-lock\` grava o novo conjunto de caminhos e hashes no lock. \`validate:framework-lock\` é somente leitura: recalcula o estado esperado e falha se houver drift. O sync não deve ser usado automaticamente para esconder uma divergência; primeiro é necessário confirmar que a mudança pertence de fato ao framework e deve fazer parte da próxima distribuição.
-### Gates locais de qualidade
-| Comando | O que verifica |
-| --- | --- |
-| \`pnpm validate:framework-lock\` | Confirma que todos os arquivos gerenciados correspondem aos caminhos e hashes registrados no lock. |
-| \`pnpm validate:skills\` | Valida estrutura, nomes, frontmatter, interfaces, links, recursos e invariantes de segurança das skills. |
-| \`pnpm test:encoding\` | Detecta UTF-8 inválido, caracteres corrompidos, *mojibake* e outros problemas de codificação textual. |
-| \`pnpm validate:source-size\` | Mede arquivos de código, aplica limites e exceções temporárias e sinaliza componentes que precisam ser divididos em módulos mais coesos. |
-| \`pnpm lint\` | Verifica formatação, consistência e regras estáticas do código. |
-| \`pnpm typecheck\` | Executa a validação de tipos TypeScript nos pacotes do workspace. |
-| \`pnpm test\` | Executa os testes automatizados dos pacotes por meio do workspace. |
-| \`pnpm build\` | Compila e empacota os componentes, além de normalizar os textos gerados. |
-Uma validação local típica, depois de atualizar o lock quando necessário, é:
-\`\`\`bash
-pnpm validate:framework-lock
-pnpm validate:skills
-pnpm test:encoding
-pnpm validate:source-size
-pnpm lint
-pnpm typecheck
-pnpm test
-pnpm build
-\`\`\`
-Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\` executa a pipeline completa do repositório, incluindo gates adicionais de ferramentas, contratos, geração, workspace, paridade de runtime e testes de release. Essa pipeline apenas valida o lock; se um arquivo gerenciado tiver sido alterado intencionalmente, o sync deve acontecer antes.
-Use a versão de pnpm fixada em \`packageManager\` (\`corepack pnpm\` quando disponível). Para uma alteração delimitada, selecione os checks pertinentes ao risco e ao diff; a lista acima não exige repetir todos os testes a cada edição documental. Qualificação de release usa os gates completos do [guia 26](.agents/zaip-aios/guides/26-qualidade-e-release.md) no candidato exato. Não confunda \`validate:github:prepared\`, execução local, push e CI terminal verde.
-Os dois pacotes públicos compartilham a mesma versão; consulte os links npm acima para identificar o \`latest\` publicado. A versão em um checkout não comprova publicação: a qualificação deve registrar a revisão exata, o resultado terminal do CI, a integridade dos TGZs e uma instalação nova do registro. O framework mantém seu cohort \`1.3.0\`, separado da versão pública. Publicação manual com token autorizado não equivale a atestado OIDC. Resultados e ressalvas ficam nas evidências da Change de release, preservando as tentativas anteriores.
-A arquitetura detalhada está resumida na seção [Arquitetura das aplicações](#arquitetura-das-aplicações) deste README.
-## Segurança com perfis de permissão
-O ZAIP-AIOS oferece dois perfis de permissão para equilibrar conveniência e contenção. O perfil selecionado por \`default_permissions\` define o limite técnico que o processo pode alcançar, enquanto instruções, Rules, hooks e skills continuam determinando o que o agente está autorizado a fazer.
-| Perfil | Filesystem nativo no Windows | Rede de comandos | Quando usar |
-| --- | --- | --- | --- |
-| \`zaip-aios-full-access\` | Escrita em \`C:\\\` inteiro, sujeita às ACLs e aos privilégios da conta Windows | Completa, com todos os domínios permitidos | Padrão humano; ainda exige autorização explícita para ações externas, destrutivas, publicação e elevação. |
-| \`zaip-aios-security\` | Escrita somente na raiz física deste repositório e seus descendentes, incluindo \`.git\`, \`.agents\` e \`.codex\`; escrita em \`~/.ssh\` apenas para fluxos Git/SSH autorizados | Limitada a \`github.com\` | Opt-in para menor privilégio; reinicie o Codex depois de selecioná-lo. |
-**Consultar funcionamento, riscos e defesa em profundidade**
-O perfil restrito usa uma tabela de permissões com a **raiz física absoluta** do repositório,
-não \`:workspace\` nem \`:workspace_roots\`. Essa escolha mantém \`.agents\`, \`.codex\` e \`.git\`
-editáveis no Windows sem liberar o restante de \`C:\\\`. Seu \`approval_policy = "never"\` não
-autoriza ações por si só: deploy, publicação, mutações remotas e ações destrutivas continuam
-dependendo de pedido explícito, instruções, Rules, hooks e skills.
-### Risco do \`zaip-aios-full-access\`
-\`zaip-aios-full-access\` é um perfil de maior risco. Ele pode alcançar outros repositórios,
-arquivos do usuário, diretórios de aplicações e do sistema, além de qualquer destino de rede que
-o host permita. Um comando incorreto, conteúdo externo malicioso ou uma dependência comprometida
-tem, portanto, impacto potencial muito maior. O perfil não concede privilégios de administrador e
-ainda respeita ACLs, políticas corporativas e arquivos em uso, mas essas barreiras não tornam o
-acesso equivalente ao perfil restrito.
-\`zaip-aios-full-access\` é o padrão humano e deve ser usado somente dentro da autoridade explícita
-do pedido. Quando uma operação puder ser executada com contenção de workspace, o usuário pode
-selecionar \`zaip-aios-security\` e reiniciar completamente o Codex para que o sandbox materialize o
-perfil escolhido. Não altere perfis apenas para contornar uma negação de permissão.
-### Defesa em profundidade
-Os dois perfis mantêm camadas compensatórias que reduzem risco, mas elas não substituem o
-isolamento nativo oferecido pelo perfil restrito:
-- carregamento da política somente em repositório confiável e escopo explícito em \`AGENTS.md\`;
-- hook \`PreToolUse\`, com verificações para classes conhecidas de escapes, referências a segredos, Git destrutivo, force push, mutações de OS, ACL, persistência, elevação e banco destrutivo, quando o host efetivamente o executa;
-- regras Codex \`forbidden\`, instruções e skills que exigem autoridade explícita e limitam o escopo de cada operação;
-- deploy GitHub delimitado por pedido explícito, preflight, branch/remoto definidos e identidade SSH escopada;
-- proteção para que tokens, chaves privadas, credenciais e valores de ambiente não sejam impressos, registrados ou incluídos em commits;
-- Tasks, Changes, Executions, Runs, write scopes, threat model, rollback, testes negativos e review independente proporcionais ao risco;
-- subagentes com responsabilidades e escopos delimitados, além de adapters com hash, framework lock e gates de regressão;
-- controles remanescentes do sistema operacional, como ACLs, privilégios da conta e políticas do host.
-O hook de segurança \`PreToolUse\` também permanece ativo no perfil full-access, sem reduzir suas permissões nativas; ele bloqueia classes destrutivas, segredos, publicação e elevação sem autorização. Os hooks de lifecycle de subagentes permanecem ativos como
-defesa em profundidade e para atribuição/telemetria. Browser, Computer Use, MCPs e demais
-integrações têm superfícies próprias e devem ser habilitados e usados apenas quando necessários.
-Para isolamento forte contra erros de escopo ou código malicioso, use o perfil restrito e, quando
-o risco justificar, uma conta, VM ou controles externos de rede e filesystem dedicados.
-O modelo de ameaça, a matriz allow/deny, todas as camadas, limitações, operação segura,
-rollout, rollback e comandos de verificação estão documentados no
-[guia completo de segurança dos perfis ZAIP-AIOS](.agents/zaip-aios/guides/10-seguranca.md).
-## Automação e integrações opcionais
-### Agendamento horário da fila pronta
-No Codex Desktop, o agendamento horário da fila pronta é configurado pela skill \`$zaip-skill-instalar-agendamento\` em uma única conversa no checkout local. A skill usa a automação nativa de tarefas agendadas para criar ou atualizar uma tarefa standalone com nome estável; ela não duplica registros e falha fechada se a capacidade \`automation_update\` não estiver disponível. A tarefa agendada chama explicitamente \`$zaip-skill-executar-fila-pronta\` em cada rodada horária.
-A rodada processa sequencialmente todo o snapshot elegível: primeiro PRDs em \`ready\`, depois SPECs \`ready\` independentes e, por último, Tasks avulsas materializadas em **Pronto para Executar**. Itens descendentes, ativos, bloqueados, falhos ou terminais ficam fora. Em **Dashboard > Trabalho (Kanban) > Pronto para Executar**, a prioridade é definida pela numeração de cima para baixo dentro do tier PRD/SPEC/Task e persiste para o scheduler em \`.agents/dashboard/work-priority.json\`; os controles acessíveis de ordenação atualizam essa numeração, e itens sem número vão para o fim pelo fallback determinístico. Um lock/lease local evita sobreposição entre rodadas.
-O repositório versiona esse contrato, mas não instala um relógio em cada clone. A tarefa agendada pertence à máquina/usuário que a criou e depende da máquina ligada, do Codex Desktop em execução e da automação nativa disponível; sem eles, a skill falha fechada e não promete execução futura.
-### Codex, documentação oficial e navegador
-O arquivo \`.codex/config.toml\` é uma configuração de projeto carregada pelo Codex somente quando o repositório é confiável. Na configuração atual do ZAIP-AIOS, ele orienta a descoberta de \`AGENTS.md\` e habilita o MCP oficial e read-only da documentação OpenAI, permitindo que o agente consulte informações atuais sobre Codex, modelos, APIs, SDKs e MCP sem depender apenas da memória do modelo. O instalador também disponibiliza a skill ZAIP de descoberta, enquanto o próprio Codex fornece recursos estáveis como shell, subagentes, apps, hooks e busca web conforme a superfície, a conta e as políticas do ambiente.
-A configuração deste checkout contém entradas habilitadas para plugins de navegador; isso não comprova instalação, disponibilidade nem permissão efetiva no host. Quando o Browser do app estiver disponível, ele pode apoiar navegação, interação e captura real da aplicação, sujeito às permissões e confirmações de ações sensíveis. Não presuma a mesma ferramenta em outra superfície Codex. Para Playwright ou outro MCP, consulte o manifesto e a política em \`.agents/tools\` antes de ativar uma implementação. Falha de captura deve ser registrada como pendência de prova, nunca como validação visual aprovada.
-## Visualização opcional da rastreabilidade no Obsidian
-A skill \`criar-pasta-obsidian\` gera em \`.local/obsidian/vault\` uma projeção local e reconstruível das relações entre PRDs, SPECs, Changes, Tasks, Executions, Runs, requisitos, evidências e testes. Ela não transforma o Obsidian em fonte de verdade, não duplica os corpos completos dos registros e não exige que o aplicativo esteja instalado para gerar ou validar a pasta.
-Na raiz do repositório, a geração ou atualização do vault utiliza:
-\`\`\`powershell
-node .agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs
-\`\`\`
-O [guia de Obsidian para rastreabilidade ZAIP](guide/CRIAR-PASTA-OBSIDIAN.md) documenta a instalação do aplicativo, a abertura da pasta como vault, a geração de uma única Task e a atualização da projeção após um \`git pull\`.
+`,A='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento é a referência pública do lifecycle implementado pelo ZAIP-AIOS. Status persistido, Run, coluna do Kanban e reconciliação possuem responsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\n`implemente` sem alvo abre somente uma Conversation de planejamento; em `draft` finaliza o plano sem executar, em `ready` executa e em `active|blocked|failed` continua, retoma ou cria rework. `desenvolva|melhore|aprimore` sempre planeja/refina/rework. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada Execution usa uma Run raiz do `zaip-agent-orchestrator`. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. Finalizador ausente, incompleto ou falho resulta em `blocked`, nunca em Task presa em `executing` ou `verifying`.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nExemplo:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração é uma interrupção retomável e resulta em `blocked`. “Cancelar a Task” é uma decisão explícita e resulta em `cancelled`.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks concluem, o macro entra em Verificação.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence próprios do pai.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação global ao abrir o dashboard, em cada turno ou em intervalo automático.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n',j=e(),M=`# ZAIP-AIOS (6 Squads + 23 Agents)\r
+\r
+## Visão rápida\r
+\r
+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.\r
+\r
+Os agentes planejam, executam, revisam, testam e validam o trabalho sob coordenação do orquestrador. A execução autorizada avança até atender aos critérios definidos ou registrar um bloqueio, falha ou limite de orçamento. Dependências externas e decisões fora da autoridade recebida continuam exigindo intervenção humana; autonomia não significa execução indefinida nem garantia de acerto.\r
+\r
+Essa abordagem busca reduzir intervenções, contexto desnecessário e retrabalho. Os percentuais de 34% e 62% apresentados adiante se referem a custo médio por tarefa e por hora nas séries históricas ilustradas, respectivamente; não medem diretamente redução de tokens nem garantem economia em uma nova entrega.\r
+\r
+Embora tenha nascido com foco em software, o ZAIP-AIOS também coordena demandas de Operações, Growth, Marketing, Branding e Vendas. O framework e o Dashboard funcionam localmente, sem exigir VPS. Autenticação, franquia, cobrança e integrações dependem do host/provider escolhido; usar uma assinatura no Codex não transforma o custo equivalente estimado em cobrança de API.\r
+\r
+<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">\r
+\r
+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.\r
+\r
+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.\r
+\r
+<img src=".agents/config/src/dashboard_pt_1_visao_geral.png" alt="Dashboard ZAIP-AIOS, Visão Geral" width="100%">\r
+\r
+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.\r
+\r
+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.\r
+\r
+<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">\r
+\r
+A fonte canônica permanece nos arquivos Git-native do repositório. Requisitos, decisões, implementações e provas podem ser versionados; só passam a estar no histórico remoto após commit e publicação explicitamente autorizada. Segredos e estado privado da máquina ficam fora desse histórico.\r
+\r
+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.\r
+\r
+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.\r
+\r
+## Comece por aqui\r
+\r
+| Se você quer… | Comece por… |\r
+| --- | --- |\r
+| Instalar e obter o primeiro resultado | [Instalação em um comando](#instalação-em-um-comando) |\r
+| Conhecer os resultados observados | [Economia medida](#economia-medida-e-meta-central-por-tarefa) |\r
+| Acompanhar trabalho, custos e qualidade | [Dashboard Local](#dashboard-local) |\r
+| Fazer uma alteração pontual | [Três formas de executar](#três-formas-de-executar) |\r
+| Planejar uma entrega técnica ou de produto | [PRD como interface de autonomia](#prd-como-interface-de-autonomia) |\r
+| Entender o método | [Método ZAIP em seis etapas](#método-zaip-em-seis-etapas) |\r
+| Conhecer os agentes especializados | [Personas e roteamento de agentes](#personas-e-roteamento-de-agentes) |\r
+| Consultar os contratos técnicos | [Referência técnica e operacional](#referência-técnica-e-operacional) |\r
+| Manter o framework | [Desenvolvimento do framework](#desenvolvimento-do-framework) |\r
+| Configurar permissões com segurança | [Segurança com perfis de permissão](#segurança-com-perfis-de-permissão) |\r
+| Avaliar lançamento, suporte e comercialização | [Prontidão para produção e comercialização](docs/PRODUCTION-COMMERCIAL-READINESS.md) |\r
+| Navegar pelos 28 guias operacionais | [Índice completo do handbook](.agents/zaip-aios/INDEX.md) |\r
+\r
+### Como interpretar esta documentação\r
+\r
+Este README e o [handbook](.agents/zaip-aios/INDEX.md) descrevem o código-fonte deste repositório. Configuração efetiva, suporte do host, pacote instalado e candidato qualificado são dimensões distintas. \`@latest\` aponta para a versão publicada, que pode não conter alterações locais. As imagens do Dashboard são ilustrações de estados anteriores, não prova visual do candidato atual.\r
+\r
+A atualização documental não aprova uma release. Consulte o [registro de limites de qualificação](docs/PRODUCTION-COMMERCIAL-READINESS.md#limites-conhecidos-da-qualificação) antes de promover o código; testes locais, paridade, CI e validação em produção devem ser comprovados separadamente.\r
+\r
+## Instalação em um comando\r
+\r
+Com Git e Node.js 22.16.0 ou superior, execute a instalação na raiz do repositório que receberá o ZAIP-AIOS. O \`init\` verifica os runtimes distribuídos e o suporte nativo a SQLite, prepara o banco local a partir dos registros canônicos e valida seu schema e sua integridade antes de informar sucesso. As dependências de execução já acompanham os bundles; não é necessário instalar pnpm, ferramentas de compilação ou um driver SQLite separado no projeto consumidor:\r
+\r
+\`\`\`bash\r
+npx @zaip-ai/cli@latest init\r
+\`\`\`\r
+\r
+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.\r
+\r
+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.\r
+\r
+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.\r
+\r
+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.\r
+\r
+## Como as camadas se complementam\r
+\r
+| Tipo | Nome | Responsabilidade |\r
+| --- | --- | --- |\r
+| **Modelo de IA (AI Model)** | **GPT-5.6 (padrão)** | Modelo principal para raciocínio, programação, uso de ferramentas, coordenação de agentes e execução de tarefas complexas. A configuração permanece aberta para testes, comparação ou substituição por outros modelos. |\r
+| **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. |\r
+| **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. |\r
+\r
+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.\r
+\r
+## Personas e roteamento de agentes\r
+\r
+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.\r
+\r
+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.\r
+\r
+### Os 23 agentes\r
+\r
+| Foto | # | Persona / função | Especialidade |\r
+| :---: | ---: | --- | --- |\r
+| <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 |\r
+| <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 |\r
+| <img src=".agents/config/src/3%20-%20Leo%20-%20Software%20Engineer.png" alt="Leo, Software Engineer" width="400"> | 3 | Leo / Software Engineer | Task genérica ponta a ponta |\r
+| <img src=".agents/config/src/4%20-%20Bia%20-%20Product%20Manager.png" alt="Bia, Product Manager" width="400"> | 4 | Bia / Product Manager | Criação/refino de PRD e análise de produto |\r
+| <img src=".agents/config/src/5%20-%20Gui%20-%20Quality%20Assurance%20Lead.png" alt="Gui, Quality Assurance Lead" width="400"> | 5 | Gui / Quality Assurance Lead | Resultado terminal restrito |\r
+| <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 |\r
+| <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 |\r
+| <img src=".agents/config/src/8%20-%20Ana%20-%20Quality%20Auditor.png" alt="Ana, Quality Auditor" width="400"> | 8 | Ana / Quality Auditor | Auditoria independente |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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\` |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+| <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 |\r
+\r
+O [Catálogo de agentes](.agents/zaip-aios/guides/18-catalogo-de-agentes.md) reúne as especialidades e responsabilidades dos agentes disponíveis no ZAIP-AIOS.\r
+\r
+### Squads organizacionais\r
+\r
+<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Estrutura organizacional dos seis squads e 23 agentes do ZAIP-AIOS" width="100%">\r
+\r
+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).\r
+\r
+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.\r
+\r
+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.\r
+\r
+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.\r
+\r
+Quando executado com a conta ChatGPT/Codex, o consumo segue as condições dessa conta. O Dashboard apresenta, quando há telemetria e preço compatível, uma estimativa de custo equivalente de API para comparação e planejamento; outros providers podem ter modalidades próprias de cobrança.\r
+\r
+## Dashboard Local\r
+\r
+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.\r
+\r
+<img src=".agents/config/src/dashboard_pt_1_visao_geral_este_mes.png" alt="Dashboard ZAIP-AIOS, Visao Geral Mes" width="100%">\r
+\r
+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.\r
+\r
+<strong>Como funciona a projeção local do Dashboard</strong>\r
+\r
+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.\r
+\r
+Não é preciso instalar servidor SQLite, DBeaver ou banco externo. O runtime usa \`node:sqlite\` e mantém a projeção em \`.local/dashboard-sqlite/read-model.sqlite\`. Abrir ou atualizar o Dashboard não autoriza reconciliação global de Runs: essa operação é separada e exige confirmação.\r
+\r
+\r
+### Kanban\r
+\r
+Organiza PRDs, SPECs e Tasks por estágio, destacando execução, verificação, conclusão, criticidade, tempo, tokens e custo observado.\r
+\r
+<img src=".agents/config/src/dashboard_pt_2_kanban.png" alt="Dashboard ZAIP-AIOS, Kanban" width="100%">\r
+\r
+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.\r
+\r
+### Monitor de Custos\r
+\r
+Consolida tokens, duração, custo equivalente estimado e cobertura por período e por unidade de trabalho, sem transformar telemetria ausente em zero.\r
+\r
+<img src=".agents/config/src/dashboard_pt_3_monitor_custos.png" alt="Dashboard ZAIP-AIOS, Monitor de Custos" width="100%">\r
+\r
+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.\r
+\r
+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.\r
+\r
+**Contrato técnico da telemetria**\r
+\r
+A telemetria do Codex usa spool local sanitizado, um \`InvocationSummary\` por invocação e chunks com\r
+manifestos mensais rastreados pelo Git. Consultas com período usam os manifestos primeiro e mantêm\r
+fallback para a projeção de Run quando não existe resumo aplicável. Cobertura incompleta continua\r
+explícita em cada métrica. A [Telemetria Git-native do Codex](.agents/zaip-aios/guides/27-telemetria-git-native.md)\r
+documenta contratos, armazenamento, integridade, recuperação e limites do rollout.\r
+\r
+\r
+### Rastreabilidade\r
+\r
+Relaciona intenção, planejamento, execução, decisões, validações e evidências para explicar de onde cada resultado veio.\r
+\r
+<img src=".agents/config/src/dashboard_pt_4_rastreabilidade.png" alt="Dashboard ZAIP-AIOS, Rastreabilidade" width="100%">\r
+\r
+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.\r
+\r
+## Configurações do projeto\r
+\r
+O Dashboard reúne a configuração do projeto em uma tela ligada ao arquivo canônico \`.agents/config/project.yaml\`. Antes de salvar, a configuração é validada pelo schema, preservando uma definição explícita do framework, das capacidades disponíveis e da visão geral dos artefatos do projeto.\r
+\r
+### Configuração da plataforma\r
+\r
+A configuração da plataforma apresenta o estado de ativação do ZAIP-AIOS e um resumo dos agentes, squads, skills, Rules, hooks e banco de dados. A mesma visão mostra os documentos de referência do projeto e indica quais deles já existem, mantendo a configuração técnica e a documentação visíveis no mesmo contexto.\r
+\r
+<img src=".agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="Dashboard ZAIP-AIOS, configuração da plataforma" width="100%">\r
+\r
+### Stack de desenvolvimento\r
+\r
+A stack de desenvolvimento descreve cada responsabilidade separadamente, com tecnologia, versão exata e referência do pacote, imagem ou serviço. No projeto, esse contrato inclui TypeScript, Node.js, Hono, Kysely, PostgreSQL via Supabase, Supabase Auth + Storage, Redis e BullMQ, permitindo que as escolhas de desenvolvimento permaneçam registradas junto da configuração do projeto.\r
+\r
+<img src=".agents/config/src/dashboard_pt_configuracao_plataforma_stack.png" alt="Dashboard ZAIP-AIOS, stack de desenvolvimento" width="100%">\r
+\r
+## O custo que importa: concluir a tarefa\r
+\r
+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.\r
+\r
+Uma forma prática de analisar o custo total é:\r
+\r
+\`\`\`text\r
+custo da tarefa concluída = modelo + ferramentas + tempo humano + rework + custo de defeitos\r
+\`\`\`\r
+\r
+## PRD como interface de autonomia\r
+\r
+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.\r
+\r
+Quando o usuário diz **“Me ajude a pensar sobre um PRD”**, o sistema mantém a interação como uma conversa de planejamento.\r
+\r
+Quando diz **“Crie um PRD”**, a IA faz até cinco perguntas importantes por turno, por no máximo três turnos. Depois, cria:\r
+\r
+- um PRD em estado \`draft\`\r
+- as SPECs técnicas necessárias\r
+- um \`PreparedPlan\`\r
+- uma lista resumida de Tasks\r
+\r
+As decisões técnicas que puderem ser delegadas são assumidas e registradas pela IA.\r
+\r
+**Detalhes de planejamento, decomposição e comandos**\r
+\r
+### Organização das SPECs\r
+\r
+Por padrão, cada PRD utiliza apenas uma SPEC, buscando economia.\r
+\r
+Uma nova SPEC só deve ser criada quando existir uma capacidade que possa ser implementada e validada de forma independente e paralela. Quando existe dependência entre partes do trabalho, elas permanecem na mesma SPEC e são organizadas pela DAG de Tasks.\r
+\r
+No runtime atual, um PRD materializa uma Execution-filho determinística para cada SPEC elegível: suas dependências permanecem dentro da SPEC e seus write scopes não conflitam com nenhum outro ramo. Cada filha executa com coordinator, estado, quota de orçamento e handoff próprios, sob uma fila limitada pelo paralelismo efetivo e por um ledger parental único de invocações; a Execution do PRD aguarda os estados terminais, integra os candidatos no handoff parental e só então aplica validação cross-SPEC e finalização. SPECs com dependência externa ou conflito de escopo permanecem na DAG global coordenadora.\r
+\r
+Antes de o PRD chegar ao estado \`ready\`, as Tasks são apenas definições de trabalho, ainda sem execução.\r
+\r
+Os comandos **“Deixe pronto para executar”**, **“Finalize o PRD”** ou **“Conclua o PRD”** criam as Tasks, Changes e Executions no estado \`planned\`, mas não iniciam a implementação.\r
+\r
+O comando **“Execute”** atua sobre o menor item informado pelo usuário, que pode ser uma Task, uma SPEC ou o PRD completo.\r
+\r
+### Limite de decomposição\r
+\r
+A escala de 1 a 5 define o limite de decomposição do PRD. Ela não representa uma meta obrigatória.\r
+\r
+* Nível 1 cobre um único fluxo vertical\r
+* Níveis 2 a 4 exigem capacidades independentes, com contratos e escopos de escrita separados\r
+* Nível 5 deve ser usado apenas em casos excepcionais com cinco implementações semelhantes e independentes\r
+\r
+Quando existe dependência entre capacidades, o trabalho deve permanecer na mesma SPEC. Projetos com mais de cinco capacidades devem ser divididos em outros PRDs ou registrar uma exceção.\r
+\r
+### Comportamento dos comandos\r
+\r
+O comando \`implemente\` considera o estado atual do trabalho:\r
+\r
+* sem alvo definido, abre uma Conversation de planejamento\r
+* em \`draft\`, conclui o plano\r
+* em \`ready\`, inicia a execução\r
+* em estados ativos ou com falha, continua, retoma ou inicia o rework\r
+\r
+Os comandos \`desenvolva\`, \`melhore\` e \`aprimore\` sempre retornam ao planejamento ou ao rework.\r
+\r
+Um PRD cancelado não pode ser alterado. Quando necessário, um novo PRD de rework é criado, preservando o vínculo e o histórico de auditoria.\r
+\r
+### Rastreamento de execução\r
+\r
+Toda criação de PRD ou SPEC é vinculada à Run responsável por meio do campo \`creation_run_id\`.\r
+\r
+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\`.\r
+\r
+\r
+## Qualidade e evidências\r
+\r
+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.\r
+\r
+As Evidence conectam validações aprovadas à Task, Change, Execution, Run, Critérios de Aceite e candidato. O [guia de revisão](.agents/zaip-aios/guides/07-revisao-e-validacao.md) explica como registrar o procedimento realmente executado e seu resultado.\r
+\r
+O contrato atual acrescenta observações \`confirmed\`, \`limited\`, \`pending\`, \`failed\` e \`not_applicable\`, sem substituir Validation/Evidence V2. A CLI valida estrutura e vínculos; não executa o comando declarado, não examina imagens e não consulta serviços automaticamente. Prova técnica não equivale a prova visual, integração real ou produção. Observações isoladas ou pendentes não aprovam uma entrega.\r
+\r
+Novos registros de Validation, Evidence, Observation e eventos de Run rejeitam padrões conhecidos de credenciais antes da persistência, sem repetir o valor sensível no erro. Use locators e resultados sanitizados; a proteção não certifica que um texto está livre de todo segredo ou dado pessoal. Históricos continuam legíveis e não são reescritos automaticamente.\r
+\r
+Para reduzir ciclos sem reduzir qualidade, escolha cedo o cenário que pode revelar uma direção errada. Repita após uma mudança concreta ou resultado que exija correção, não apenas porque o relógio avançou. A indisponibilidade da mesma ferramenta tem fallback finito e pendência explícita; a suficiência da prova continua sendo responsabilidade do executor/revisor. Consulte o [contrato canônico de prova observável](.agents/skills/zaip-skill-change/references/observable-evidence.md).\r
+\r
+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.\r
+\r
+\r
+## Economia medida e meta central por tarefa\r
+\r
+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.\r
+\r
+### Análise de custo por tarefa\r
+\r
+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.\r
+\r
+<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">\r
+\r
+### Análise de custo por hora\r
+\r
+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.\r
+\r
+<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">\r
+\r
+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.\r
+\r
+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.\r
+\r
+| O que é reduzido | O que representa | Baseline sem a otimização | Com ZAIP-AIOS | Economia | Situação da métrica |\r
+| --- | --- | ---: | ---: | ---: | --- |\r
+| **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%). |\r
+| **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%). |\r
+| **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. |\r
+| **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. |\r
+| **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. |\r
+\r
+\r
+### Metodologia da comparação\r
+\r
+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.\r
+\r
+Os indicadores que compõem a análise são:\r
+\r
+- tokens e custo equivalente de API de todas as chamadas até a conclusão;\r
+- duração e número de ciclos/retries;\r
+- tempo humano de revisão e correção;\r
+- taxa de rework e defeitos encontrados após a entrega;\r
+- cobertura de testes, reviews e evidências dos Critérios de Aceite.\r
+\r
+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).\r
+\r
+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.\r
+\r
+## Comparação com os principais frameworks concorrentes\r
+\r
+Esta seção preserva um recorte histórico, não uma pesquisa de mercado atualizada nem certificação de produção. As notas abaixo não substituem a qualificação do candidato atual e não foram recalculadas nesta revisão documental.\r
+\r
+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.\r
+\r
+| Produto | Nota /100 | Justificativa da nota | Posicionamento competitivo |\r
+|---|---:|---|---|\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+| 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. |\r
+\r
+**Consultar a matriz técnica dos dez critérios**\r
+\r
+| Tópico (0–10) | ZAIP | OpenClaw | Traycer | Kilo | Hermes | AIOX | Roo Code | OpenCode | TLC Spec-Driven | Superpowers | OpenSpec |\r
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|\r
+| T1 — SDD e rastreabilidade | 10 | 6 | 7 | 6 | 6 | 9 | 6 | 3 | 9 | 8 | 9 |\r
+| T2 — Loop planejar–editar–testar–corrigir | 9 | 7 | 9 | 10 | 7 | 9 | 9 | 8 | 9 | 9 | 6 |\r
+| T3 — Multiagentes e isolamento | 10 | 9 | 9 | 8 | 7 | 9 | 8 | 4 | 8 | 9 | 5 |\r
+| T4 — Arquitetura e repositório | 10 | 8 | 9 | 8 | 7 | 8 | 8 | 8 | 7 | 7 | 8 |\r
+| T5 — Testes, review e evidência | 10 | 9 | 9 | 9 | 8 | 9 | 9 | 5 | 9 | 9 | 8 |\r
+| T6 — Recovery e idempotência | 10 | 7 | 9 | 7 | 7 | 8 | 7 | 6 | 8 | 8 | 7 |\r
+| T7 — Supply chain | 9 | 8 | 8 | 8 | 8 | 7 | 8 | 6 | 7 | 7 | 6 |\r
+| T8 — Memória de codebase | 9 | 8 | 9 | 8 | 9 | 9 | 8 | 7 | 9 | 8 | 8 |\r
+| T9 — Telemetria/custo por tarefa de programação | 9 | 6 | 5 | 6 | 6 | 6 | 6 | 4 | 5 | 4 | 4 |\r
+| T10 — DX CLI/IDE, debug, review, setup e Codex-first | 9 | 5 | 9 | 10 | 6 | 8 | 10 | 9 | 9 | 9 | 9 |\r
+\r
+\r
+## Da conversa ao trabalho executável\r
+\r
+O framework ZAIP-AIOS transforma linguagem natural em engenharia estruturada. O usuário pode enviar uma mensagem curta, manter uma conversa de refinamento ou fornecer a transcrição de um áudio longo explicando contexto, restrições e resultado desejado. O framework avalia complexidade, dependências, amplitude e risco para propor a entrada adequada: uma Task para trabalho direto, uma SPEC para uma entrega técnica com múltiplas Tasks ou um PRD para uma iniciativa de produto composta por uma ou mais SPECs. A criticidade \`leve\`, \`padrão\` ou \`crítica\` determina a profundidade de planejamento, revisão, segurança e evidência exigida; nenhum artefato fica fechado à revisão humana.\r
+\r
+Isso permite sair de uma conversa livre sem cair em *vibe coding*: perguntas e análises read-only permanecem Conversations sem Task; pedidos de ação tornam-se trabalho executável. Antes da mutação, a intenção é convertida em requisitos, critérios de aceite, escopo, dependências e write scopes, e uma Task com Run raiz de orquestração entra em Execução. Consulte [Lifecycle de Conversations, Tasks, SPECs e PRDs](.agents/zaip-aios/guides/28-lifecycle-completo.md).\r
+\r
+## Método ZAIP em seis etapas\r
+\r
+| Etapa | Artefatos | O que acontece |\r
+| --- | --- | --- |\r
+| **1. Definição** | PRD + Requirements | Registra objetivo, contexto, público, restrições, resultado esperado e Critérios de Aceite que definem o trabalho. |\r
+| **2. Planejamento** | SPEC + Changes | Descreve escopo, solução, arquitetura, riscos e mudanças previstas antes da execução, seguindo SDD. |\r
+| **3. Execução** | Tasks + DAG + Executions + Runs | Coordena Tasks, dependências, agentes e arquivos produzidos; registra cada tentativa e seu consumo observável. |\r
+| **4. Decisões** | Decisions (Human + AI / Planning + Execution) | Preserva decisões humanas e da IA tomadas durante planejamento, execução, revisão e reparo, com contexto e consequências. |\r
+| **5. Verificação** | Tests + Reviews + Evals + Checks | Executa os mecanismos de qualidade e compara o resultado observado com os requisitos e Critérios de Aceite. |\r
+| **6. Evidências** | Evidence + Results + Traceability | Coleta, registra e relaciona as provas produzidas pela verificação às Tasks, Changes, Runs e aos Critérios de Aceite; o trabalho só é concluído quando as evidências são suficientes e reproduzíveis. |\r
+\r
+O método mantém intenção e execução separadas. PRD e SPEC explicam o que se pretende entregar; Change, Task, Execution e Run registram como o trabalho foi realizado; Decisions explicam por que caminhos relevantes foram escolhidos; a Verificação executa testes, reviews, evals e checks; e Evidence preserva os resultados observados e sua relação com os Critérios de Aceite. Assim, “concluído” é um estado demonstrado por diff, resultado e evidência reproduzível, não apenas declarado por um agente.\r
+\r
+## Cadeia completa de execução\r
+\r
+Os conceitos abaixo formam o vocabulário técnico usado para ligar intenção, planejamento, execução e prova sem perder o histórico.\r
+\r
+**Consultar o glossário completo do lifecycle**\r
+\r
+| Conceito | Responsabilidade |\r
+| --- | --- |\r
+| **Rule** | Regra durável de comportamento, arquitetura, segurança, contexto ou qualidade que o Codex deve seguir. |\r
+| **Requirement** | Obrigação verificável do produto, acompanhada de Critérios de Aceite. |\r
+| **PRD** | Documento de Requisitos do Produto que governa uma iniciativa e organiza uma ou mais SPECs. |\r
+| **SPEC** | Especificação técnica SDD que detalha solução, escopo, riscos, Changes, Tasks e DAG. |\r
+| **Change** | Narrativa viva de uma mudança planejada e executada: decisões, arquivos afetados, desvios, testes, evidências, rollout, rollback e resultado. |\r
+| **Task** | Menor unidade executável, com objetivo, risco, prioridade, dependências, write scopes e critérios de aceite. |\r
+| **DAG** | Grafo acíclico que ordena dependências, identifica paralelismo seguro e impede execução fora da sequência necessária. |\r
+| **Execution** | Unidade de interação ou entrega, correlacionada ao turno observável: \`interaction\` registra conversa/definição; \`delivery\` coordena trabalho materializado. A idempotência depende da identidade observada do turno; continuação pode reutilizar a delivery vigente. |\r
+| **Run / Sub-Run** | Run de captura ou do agente orquestrador possui \`parent_run_id: null\`; Sub-Run é cada chamada de subagente relacionada por \`parent_run_id\`. Novos registros usam \`run_role: intake|orchestrator|subagent\`; cada chamada fixa modelo e effort e agrega suas Calls internas. |\r
+| **Decision** | Decisão humana ou da IA com contexto, alternativa escolhida, motivo, consequências e possibilidade de rollback. |\r
+| **Evidence** | Prova associada à Task e aos Critérios de Aceite: teste, diff, review, check, relatório ou resultado reproduzível. |\r
+| **Eval** | Avaliação determinística ou orientada por rubrica que mede qualidade, regressão, aderência e performance. |\r
+\r
+\r
+## Três formas de executar\r
+\r
+1. **Task-first:** executa uma única Task independente para mudanças diretas e bem delimitadas.\r
+2. **SPEC:** executa um conjunto de Tasks relacionadas, coordenadas por uma DAG e governadas pela mesma especificação técnica.\r
+3. **PRD:** executa uma iniciativa completa, selecionando uma ou mais SPECs, cada uma com suas Changes, Tasks e dependências.\r
+\r
+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.\r
+\r
+**Políticas técnicas de execução e assurance**\r
+\r
+Conversation e Task-first preservam a seleção manual do host; o default do projeto não é aplicado automaticamente a uma Task avulsa. A política automática aceita origens SPEC/PRD configuradas em \`automatic_sources\`, com velocidade \`standard\`. Modelo e effort ficam fixos em cada Run/Sub-Run; capacidade ou velocidade indisponível no host não pode ser presumida pelo ZAIP. Consulte a [política de modelos](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).\r
+\r
+O intake correlaciona o turno observável à Execution. \`prepare\` valida o plano, sem autorizar implementação; \`ready\` materializa trabalho preparado e \`execute\` inicia a entrega autorizada. Toda delivery e interaction com descendentes exigem executor elegível e \`zaip-agent-finalizer\` por último. Interaction read-only sem descendentes termina após a resposta, sem esse circuito. Publicação puramente Git é uma exceção: não materializa lifecycle. SPEC/PRD permanecem ativos entre Runs filhas e só são entregues por gates parentais.\r
+\r
+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](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).\r
+\r
+\r
+## Princípios de engenharia autônoma\r
+\r
+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.\r
+\r
+O padrão do schema é \`execution.runtime: manual\` quando a opção está ausente; este checkout optou por \`autonomous\` em \`project.yaml\`. A configuração não dispensa pedido de execução nem autoriza publicar. Consulte sempre o arquivo efetivo do projeto, não apenas o default descrito no guia.\r
+\r
+- **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.\r
+- **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.\r
+- **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.\r
+- **Autonomia dentro de limites:** subagentes trabalham com DAG, write scopes, sandbox, approvals, budgets, regras de segurança e gates proporcionais ao risco.\r
+- **Contexto progressivo:** cada agente recebe apenas Rules, Requirements, skills e evidências relevantes para seu papel, reduzindo ruído, custo e perda de contexto.\r
+- **Conclusão baseada em prova:** testes, review, evals, checks e Evidence precisam cobrir os Critérios de Aceite antes da entrega.\r
+- **Histórico recuperável:** decisões, mudanças, tentativas, falhas, retries, reparos e rollback permanecem vinculados, permitindo pausar, retomar e auditar o trabalho.\r
+- **Observabilidade honesta:** tokens, custo, tempo, cobertura e performance são medidos por escopo; ausência de telemetria permanece explícita em vez de gerar precisão fictícia.\r
+\r
+O intake captura uma vez por turno observável e reutiliza o foco válido em continuações; publicação puramente Git não cria lifecycle. Perguntas, feedbacks e análises read-only usam Execution \`interaction\`, sem Task ou Change artificial. A criação/refino explícito de PRD/SPEC \`draft\` pode persistir esses macros e o PreparedPlan em interaction, sem delivery. Fora dessa exceção, uma edição avulsa independente materializa e inicia Task, Change, delivery e Run antes da primeira mutação; preparação explicitamente solicitada pode parar em Pronto para Executar. PRD \`draft\` ocupa Definição e SPEC \`draft\` ocupa Planejamento; Tasks nunca ocupam essas colunas.\r
+\r
+## Graph Engineering e Loop Engineering\r
+\r
+<img src=".agents/config/src/zaip-aios-obsidian.png" alt="Zaip AIOS no Obsidian" width="100%">\r
+\r
+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.\r
+\r
+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.\r
+\r
+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.\r
+\r
+### Fluxo resumido\r
+\r
+Um fluxo de entrega com revisão independente é **entrada → Dave → executor por capacidade → Nanda (review) → Gui (finalização)**. A revisão deve atender ao perfil de assurance; não é obrigatório expandir todo trabalho para o mesmo conjunto de agentes. Todos os filhos são coordenados pela orquestração; a sequência não significa que um trabalhador chama o próximo.\r
+\r
+Os cenários completos ficam no [guia de fluxos e roteamento](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md), em texto estável para o GitHub.\r
+\r
+### Fluxos resumidos\r
+\r
+O lifecycle segue **Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído**. Bloqueado, Falhado e Cancelado são saídas alternativas.\r
+\r
+Task, SPEC e PRD mantêm fluxos independentes; Conversation usa uma Execution interaction e não cria Task artificial. A Task direta inicia imediatamente, enquanto a preparada aguarda execute.\r
+\r
+![Lifecycles de Task, SPEC e PRD](.agents/zaip-aios/guides/assets/diagrams/lifecycles-task-spec-prd.png)\r
+\r
+Os fluxos detalhados de roteamento, entrada, planejamento, rework, demanda crítica, seleção de modelo, os 23 agentes e orquestração de Task estão no [guia de fluxos e roteamento](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md).\r
+\r
+## Referência técnica e operacional\r
+\r
+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.\r
+\r
+## Estrutura atual de \`.agents\`\r
+\r
+**Consultar a árvore de diretórios e as responsabilidades técnicas**\r
+\r
+\`\`\`text\r
+.agents/\r
+├── config/\r
+│   ├── project.yaml\r
+│   ├── framework.lock.yaml\r
+│   ├── agents/catalog.yaml\r
+│   └── profiles/clients.yaml\r
+├── dashboard/\r
+│   ├── zaip-dashboard-windows.exe\r
+│   ├── zaip-dashboard-linux.sh\r
+│   ├── zaip-dashboard-mac.command\r
+│   ├── apps/frontend/\r
+│   ├── modules/{operations,cost-monitor,traceability}/\r
+│   ├── packages/\r
+│   └── tests/e2e/\r
+├── design/\r
+│   ├── DESIGN.md\r
+│   ├── tokens.json\r
+│   ├── zaip-design.exe\r
+│   ├── apps/catalog/\r
+│   └── packages/\r
+├── branding/                         # artefatos de negócio, criada sob demanda\r
+├── marketing/                        # artefatos de negócio, criada sob demanda\r
+├── sales/                            # artefatos de negócio, criada sob demanda\r
+├── growth/                           # artefatos de negócio, criada sob demanda\r
+├── records/\r
+│   ├── prds/<ano>/<mês>/\r
+│   ├── specs/<ano>/<mês>/\r
+│   ├── changes/<ano>/<mês>/\r
+│   ├── tasks/<ano>/<mês>/\r
+│   ├── executions/<ano>/<mês>/\r
+│   ├── runs/<ano>/<mês>/\r
+│   ├── lifecycle/                    # manifests, índices e projeções\r
+│   └── telemetry/<ano>/<mês>/writers/<writer-id>/{manifest.json,chunks/}\r
+├── rules/\r
+│   ├── core.md\r
+│   ├── workflow.md\r
+│   └── *.md                          # Rules gerenciadas e locais, layout plano\r
+├── requirements/\r
+├── skills/\r
+├── tools/\r
+│   ├── catalog.yaml\r
+│   ├── {mcp,api}/\r
+│   ├── policies/\r
+│   ├── profiles/\r
+│   ├── runtime/\r
+│   └── servers/\r
+├── zaip-aios/\r
+│   ├── INDEX.md\r
+│   └── guides/\r
+├── runtime/\r
+│   └── bin/zaip.mjs                  # CLI instalado e metadados de distribuição\r
+├── .env.example\r
+└── .gitignore\r
+.local/                              # na raiz do workspace; ignorado pelo Git\r
+├── claims/                          # claims atômicos de lifecycle\r
+├── codex-telemetry-spool/v1/          # captura sanitizada, privada e recuperável\r
+└── dashboard-sqlite/                 # read model descartável\r
+\`\`\`\r
+\r
+As pastas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` são áreas de artefatos de negócio criadas sob demanda. A existência e o conteúdo variam por projeto; não é necessário criar pastas vazias.\r
+\r
+| Caminho | Responsabilidade |\r
+| --- | --- |\r
+| \`config/\` | Configuração do projeto, perfis de clientes e agentes, maturidade de capacidades e lock de integridade dos arquivos gerenciados. |\r
+| \`dashboard/\` | Dashboard operacional local com Kanban, custos, tempo, tokens e rastreabilidade; consulta projeções reconstruíveis dos registros canônicos, incluindo SQLite. |\r
+| \`design/\` | Design system do ZAIP, tokens visuais, catálogo de componentes e launcher local de inspeção. |\r
+| \`branding/\` | Artefatos de negócio de branding, como Brandbook, plataforma de marca e governança de identidade; é criada sob demanda. |\r
+| \`marketing/\` | Artefatos de negócio de estratégia, campanhas, conteúdo e ativos de marketing; é criada sob demanda. |\r
+| \`sales/\` | Artefatos de negócio de metodologia comercial, qualificação, playbooks, scripts e handoffs; é criada sob demanda. |\r
+| \`growth/\` | Artefatos de negócio de estratégia de crescimento, RevOps e experimentos; é criada sob demanda. |\r
+| \`records/\` | Fonte canônica Git-native de PRDs, SPECs, Changes, Tasks, Executions e Runs. \`records/lifecycle\` contém manifests, índices, chunks e resumos para descoberta e paginação sem varrer o histórico. |\r
+| \`requirements/\` | Requisitos duráveis e Critérios de Aceite de lifecycle, execução, custos, contexto, dashboard, arquitetura e design system. |\r
+| \`rules/\` | Rules canônicas do framework e Rules locais do projeto, todas diretamente neste diretório. |\r
+| \`skills/\` | Workflows reutilizáveis que transformam conversas em Requirements, Tasks, SPECs e PRDs e orientam execução, revisão, segurança, custos, contexto e ferramentas. |\r
+| \`tools/\` | Catálogo de MCPs e APIs, políticas de aprovação e segredos, perfis de ativação, doctors e servidores locais gerados de maneira auditável. |\r
+| \`zaip-aios/\` | Handbook operacional com índice de baixo custo de contexto e guias de instalação, execução, revisão, agentes, custos, segurança e integração com Codex. |\r
+| \`../.local/\` | Diretório na raiz do workspace com claims, writer ID, spool sanitizado e SQLite descartável; fica fora do Git. O Dashboard consulta a projeção, mas os registros canônicos permanecem em \`records/\`. |\r
+\r
+\`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.\r
+\r
+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 está em \`packages/local-runtime\`, não em \`apps/backend\`. Os módulos \`operations\`, \`cost-monitor\` e \`traceability\` consomem read models derivados, com consultas SQLite no runtime atual e caminhos de compatibilidade em memória. A API é predominantemente de leitura, com endpoints controlados para ações como configuração, prioridade, refresh e reconciliação explícita; isso não é permissão para alterações arbitrárias. Os launchers Windows, Linux e macOS ficam diretamente em \`.agents/dashboard\`; sua presença no template não comprova execução nos três ambientes.\r
+\r
+\r
+## Arquitetura das aplicações\r
+\r
+**Consultar layout, dependências e limites de código**\r
+\r
+Quando essas superfícies existirem, a estrutura canônica é:\r
+\r
+\`\`\`text\r
+apps/\r
+├── frontend/       # UI do produto e composition root do cliente\r
+├── backend/        # APIs, workers e composition roots de servidor\r
+└── site/           # landing page e site público, implantável separadamente\r
+modules/<area>/     # capacidades de negócio e seus contratos públicos\r
+packages/<library>/ # bibliotecas técnicas reutilizáveis\r
+tests/e2e/          # fluxos que atravessam aplicações\r
+\`\`\`\r
+\r
+A direção de dependência é \`apps -> modules -> packages\`. Esta arquitetura descreve exclusivamente o código das aplicações do produto consumidor, não o dashboard ZAIP nem os domínios de negócio. As áreas \`branding/\`, \`marketing/\`, \`sales/\` e \`growth/\` ficam em \`.agents\` como pastas de artefatos de negócio criadas sob demanda; elas não são pastas de aplicação. \`apps/site\` nunca importa o dashboard, não lê \`.agents\` e não depende de implementação privada do backend. Pastas de superfícies ausentes não precisam ser criadas vazias. Testes unitários ficam junto do código; jornadas cross-app ficam em \`tests/e2e\`.\r
+\r
+Arquivos-fonte com 401–800 linhas geram warning e arquivos com 801 ou mais linhas geram erro, salvo exceções explícitas. O gate ignora código gerado, distribuição, vendor, dados e lockfiles. A lista em [source-size-baseline.json](scripts/source-size-baseline.json) inclui legado de pacotes e Dashboard, com limite congelado, responsável, motivo e validade; isso não autoriza aumentar os limites para ocultar crescimento.\r
+\r
+\r
+## Desenvolvimento do framework\r
+\r
+**Consultar contratos para mantenedores e contribuidores**\r
+\r
+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.\r
+\r
+### Repositório-fonte e projeto consumidor\r
+\r
+- **Repositório-fonte:** contém a implementação oficial do ZAIP-AIOS, seus pacotes, dashboard, Rules, Requirements, skills, ferramentas e artefatos de distribuição. Mudanças intencionais nesses componentes precisam passar pelos gates de integridade, qualidade, testes e build.\r
+- **Projeto consumidor:** recebe uma versão publicada do framework dentro de \`.agents\`. O arquivo \`framework.lock.yaml\` é atualizado somente pelos fluxos transacionais de instalação ou upgrade do CLI; o projeto consumidor não executa \`sync:framework-lock\` para aceitar alterações locais.\r
+\r
+Configurações do projeto consumidor permanecem em \`.agents/config/project.yaml\`; Rules adicionais ficam diretamente em \`.agents/rules/*.md\` e não entram no lock do framework. Arquivos administrados pela distribuição não devem ser modificados e depois incorporados ao lock apenas para silenciar uma divergência.\r
+\r
+### Integridade dos arquivos gerenciados\r
+\r
+O \`framework.lock.yaml\` é um manifesto mecânico de integridade, não um lock de dependências como \`pnpm-lock.yaml\`. Ele registra os caminhos e hashes SHA-256 dos arquivos que pertencem à distribuição do ZAIP-AIOS, permitindo detectar alteração acidental, arquivo ausente ou conteúdo diferente do release esperado. Ele não armazena segredos, telemetria ou histórico de execução.\r
+\r
+Quando um mantenedor altera intencionalmente Rules, Requirements, skills ou outro arquivo gerenciado no repositório-fonte, deve revisar a mudança e então regenerar os hashes:\r
+\r
+\`\`\`bash\r
+pnpm sync:framework-lock\r
+pnpm validate:framework-lock\r
+\`\`\`\r
+\r
+\`sync:framework-lock\` grava o novo conjunto de caminhos e hashes no lock. \`validate:framework-lock\` é somente leitura: recalcula o estado esperado e falha se houver drift. O sync não deve ser usado automaticamente para esconder uma divergência; primeiro é necessário confirmar que a mudança pertence de fato ao framework e deve fazer parte da próxima distribuição.\r
+\r
+### Gates locais de qualidade\r
+\r
+| Comando | O que verifica |\r
+| --- | --- |\r
+| \`pnpm validate:framework-lock\` | Confirma que todos os arquivos gerenciados correspondem aos caminhos e hashes registrados no lock. |\r
+| \`pnpm validate:skills\` | Valida estrutura, nomes, frontmatter, interfaces, links, recursos e invariantes de segurança das skills. |\r
+| \`pnpm test:encoding\` | Detecta UTF-8 inválido, caracteres corrompidos, *mojibake* e outros problemas de codificação textual. |\r
+| \`pnpm validate:source-size\` | Mede arquivos de código, aplica limites e exceções temporárias e sinaliza componentes que precisam ser divididos em módulos mais coesos. |\r
+| \`pnpm lint\` | Verifica formatação, consistência e regras estáticas do código. |\r
+| \`pnpm typecheck\` | Executa a validação de tipos TypeScript nos pacotes do workspace. |\r
+| \`pnpm test\` | Executa os testes automatizados dos pacotes por meio do workspace. |\r
+| \`pnpm build\` | Compila e empacota os componentes, além de normalizar os textos gerados. |\r
+\r
+Uma validação local típica, depois de atualizar o lock quando necessário, é:\r
+\r
+\`\`\`bash\r
+pnpm validate:framework-lock\r
+pnpm validate:skills\r
+pnpm test:encoding\r
+pnpm validate:source-size\r
+pnpm lint\r
+pnpm typecheck\r
+pnpm test\r
+pnpm build\r
+\`\`\`\r
+\r
+Antes de integrar uma mudança relevante ou preparar um release, \`pnpm verify\` executa a pipeline completa do repositório, incluindo gates adicionais de ferramentas, contratos, geração, workspace, paridade de runtime e testes de release. Essa pipeline apenas valida o lock; se um arquivo gerenciado tiver sido alterado intencionalmente, o sync deve acontecer antes.\r
+\r
+Use a versão de pnpm fixada em \`packageManager\` (\`corepack pnpm\` quando disponível). Para uma alteração delimitada, selecione os checks pertinentes ao risco e ao diff; a lista acima não exige repetir todos os testes a cada edição documental. Qualificação de release usa os gates completos do [guia 26](.agents/zaip-aios/guides/26-qualidade-e-release.md) no candidato exato. Não confunda \`validate:github:prepared\`, execução local, push e CI terminal verde.\r
+\r
+Os dois pacotes públicos compartilham a mesma versão; consulte os links npm acima para identificar o \`latest\` publicado. A versão em um checkout não comprova publicação: a qualificação deve registrar a revisão exata, o resultado terminal do CI, a integridade dos TGZs e uma instalação nova do registro. O framework mantém seu cohort \`1.3.0\`, separado da versão pública. Publicação manual com token autorizado não equivale a atestado OIDC. Resultados e ressalvas ficam nas evidências da Change de release, preservando as tentativas anteriores.\r
+\r
+A arquitetura detalhada está resumida na seção [Arquitetura das aplicações](#arquitetura-das-aplicações) deste README.\r
+\r
+\r
+## Segurança com perfis de permissão\r
+\r
+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.\r
+\r
+| Perfil | Filesystem nativo no Windows | Rede de comandos | Quando usar |\r
+| --- | --- | --- | --- |\r
+| \`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. |\r
+| \`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. |\r
+\r
+**Consultar funcionamento, riscos e defesa em profundidade**\r
+\r
+O perfil restrito usa uma tabela de permissões com a **raiz física absoluta** do repositório,\r
+não \`:workspace\` nem \`:workspace_roots\`. Essa escolha mantém \`.agents\`, \`.codex\` e \`.git\`\r
+editáveis no Windows sem liberar o restante de \`C:\\\`. Seu \`approval_policy = "never"\` não\r
+autoriza ações por si só: deploy, publicação, mutações remotas e ações destrutivas continuam\r
+dependendo de pedido explícito, instruções, Rules, hooks e skills.\r
+\r
+### Risco do \`zaip-aios-full-access\`\r
+\r
+\`zaip-aios-full-access\` é um perfil de maior risco. Ele pode alcançar outros repositórios,\r
+arquivos do usuário, diretórios de aplicações e do sistema, além de qualquer destino de rede que\r
+o host permita. Um comando incorreto, conteúdo externo malicioso ou uma dependência comprometida\r
+tem, portanto, impacto potencial muito maior. O perfil não concede privilégios de administrador e\r
+ainda respeita ACLs, políticas corporativas e arquivos em uso, mas essas barreiras não tornam o\r
+acesso equivalente ao perfil restrito.\r
+\r
+\`zaip-aios-full-access\` é o padrão humano e deve ser usado somente dentro da autoridade explícita\r
+do pedido. Quando uma operação puder ser executada com contenção de workspace, o usuário pode\r
+selecionar \`zaip-aios-security\` e reiniciar completamente o Codex para que o sandbox materialize o\r
+perfil escolhido. Não altere perfis apenas para contornar uma negação de permissão.\r
+\r
+### Defesa em profundidade\r
+\r
+Os dois perfis mantêm camadas compensatórias que reduzem risco, mas elas não substituem o\r
+isolamento nativo oferecido pelo perfil restrito:\r
+\r
+- carregamento da política somente em repositório confiável e escopo explícito em \`AGENTS.md\`;\r
+- hook \`PreToolUse\`, com verificações para classes conhecidas de escapes, referências a segredos, Git destrutivo, force push, mutações de OS, ACL, persistência, elevação e banco destrutivo, quando o host efetivamente o executa;\r
+- regras Codex \`forbidden\`, instruções e skills que exigem autoridade explícita e limitam o escopo de cada operação;\r
+- deploy GitHub delimitado por pedido explícito, preflight, branch/remoto definidos e identidade SSH escopada;\r
+- proteção para que tokens, chaves privadas, credenciais e valores de ambiente não sejam impressos, registrados ou incluídos em commits;\r
+- Tasks, Changes, Executions, Runs, write scopes, threat model, rollback, testes negativos e review independente proporcionais ao risco;\r
+- subagentes com responsabilidades e escopos delimitados, além de adapters com hash, framework lock e gates de regressão;\r
+- controles remanescentes do sistema operacional, como ACLs, privilégios da conta e políticas do host.\r
+\r
+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\r
+defesa em profundidade e para atribuição/telemetria. Browser, Computer Use, MCPs e demais\r
+integrações têm superfícies próprias e devem ser habilitados e usados apenas quando necessários.\r
+Para isolamento forte contra erros de escopo ou código malicioso, use o perfil restrito e, quando\r
+o risco justificar, uma conta, VM ou controles externos de rede e filesystem dedicados.\r
+\r
+O modelo de ameaça, a matriz allow/deny, todas as camadas, limitações, operação segura,\r
+rollout, rollback e comandos de verificação estão documentados no\r
+[guia completo de segurança dos perfis ZAIP-AIOS](.agents/zaip-aios/guides/10-seguranca.md).\r
+\r
+\r
+## Automação e integrações opcionais\r
+\r
+### Agendamento horário da fila pronta\r
+\r
+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.\r
+\r
+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.\r
+\r
+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.\r
+\r
+### Codex, documentação oficial e navegador\r
+\r
+O arquivo \`.codex/config.toml\` é uma configuração de projeto carregada pelo Codex somente quando o repositório é confiável. Na configuração atual do ZAIP-AIOS, ele orienta a descoberta de \`AGENTS.md\` e habilita o MCP oficial e read-only da documentação OpenAI, permitindo que o agente consulte informações atuais sobre Codex, modelos, APIs, SDKs e MCP sem depender apenas da memória do modelo. O instalador também disponibiliza a skill ZAIP de descoberta, enquanto o próprio Codex fornece recursos estáveis como shell, subagentes, apps, hooks e busca web conforme a superfície, a conta e as políticas do ambiente.\r
+\r
+A configuração deste checkout contém entradas habilitadas para plugins de navegador; isso não comprova instalação, disponibilidade nem permissão efetiva no host. Quando o Browser do app estiver disponível, ele pode apoiar navegação, interação e captura real da aplicação, sujeito às permissões e confirmações de ações sensíveis. Não presuma a mesma ferramenta em outra superfície Codex. Para Playwright ou outro MCP, consulte o manifesto e a política em \`.agents/tools\` antes de ativar uma implementação. Falha de captura deve ser registrada como pendência de prova, nunca como validação visual aprovada.\r
+\r
+## Visualização opcional da rastreabilidade no Obsidian\r
+\r
+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.\r
+\r
+Na raiz do repositório, a geração ou atualização do vault utiliza:\r
+\r
+\`\`\`powershell\r
+node .agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs\r
+\`\`\`\r
+\r
+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\`.\r
 `,N=t(),P=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,"../../../../zaip-aios/guides/18-catalogo-de-agentes.md":b,"../../../../zaip-aios/guides/19-assurance-e-autonomia.md":x,"../../../../zaip-aios/guides/20-instalacao-detalhada.md":S,"../../../../zaip-aios/guides/21-telemetria-monitor-custos.md":C,"../../../../zaip-aios/guides/22-fluxos-e-roteamento.md":w,"../../../../zaip-aios/guides/23-orquestracao-de-modelos.md":T,"../../../../zaip-aios/guides/24-calculo-de-custos-openai.md":E,"../../../../zaip-aios/guides/25-fontes-de-precos-openai.md":D,"../../../../zaip-aios/guides/26-qualidade-e-release.md":O,"../../../../zaip-aios/guides/27-telemetria-git-native.md":k,"../../../../zaip-aios/guides/28-lifecycle-completo.md":A});function F({locale:e,onClose:t}){let r=(0,j.useMemo)(()=>n(e,M,P),[e]),i=r.filter(e=>e.id!==`readme`),[a,o]=(0,j.useState)(`readme`),[s,c]=(0,j.useState)(`rendered`),l=r.find(e=>e.id===a)??r[0];return(0,N.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,N.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,N.jsxs)(`header`,{children:[(0,N.jsxs)(`div`,{children:[(0,N.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,N.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,N.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,N.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,N.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,N.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,N.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,N.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,N.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,N.jsxs)(`article`,{children:[(0,N.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,N.jsx)(`h3`,{children:l?.title}),(0,N.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,N.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,N.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,N.jsx)(`div`,{className:`dashboard-help-sections`,children:U(l?.content??``,e).map(e=>(0,N.jsxs)(`section`,{children:[(0,N.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,N.jsx)(I,{content:e.content}):(0,N.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function I({content:e}){return H(L(e),V).map(({key:e,value:t})=>t.kind===`table`?(0,N.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,N.jsxs)(`table`,{children:[(0,N.jsx)(`thead`,{children:(0,N.jsx)(`tr`,{children:H(t.headers,e=>e).map(({key:e,value:t})=>(0,N.jsx)(`th`,{children:B(t)},e))})}),(0,N.jsx)(`tbody`,{children:H(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,N.jsx)(`tr`,{children:H(t,e=>e).map(({key:e,value:t})=>(0,N.jsx)(`td`,{children:B(t)},e))},e))})]})},e):(0,N.jsx)(`pre`,{children:t.content},e))}function L(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&&R(o)){i();let r=z(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(z(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function R(e){return z(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function z(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function B(e){return H(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,N.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,N.jsx)(j.Fragment,{children:t},e))}function V(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function H(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 U(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`