@zaip-ai/cli 1.0.6 → 1.0.7

package/templates/.zaip-aios/templates/tools/runtime/api-mcp-runtime.test.mjs

@@ -1,56 +0,0 @@
-import assert from "node:assert/strict";
-import test from "node:test";
-import { callTool, doctor } from "./api-mcp-runtime.mjs";
-
-const definition = {
-  id: "fixture",
-  baseUrl: "https://api.example.com",
-  allowedHosts: ["api.example.com"],
-  auth: { env: [], headers: [] },
-  tools: [
-    {
-      name: "items_list",
-      description: "List",
-      method: "GET",
-      path: "/items",
-      access: "read",
-      inputSchema: {
-        type: "object",
-        additionalProperties: false,
-        properties: { limit: { type: "integer" } },
-      },
-    },
-  ],
-};
-
-test("doctor validates a credential-free definition", () => {
-  assert.deepEqual(doctor(definition), {
-    id: "fixture",
-    ready: true,
-    transport: "stdio",
-    tools: 1,
-    findings: [],
-  });
-});
-
-test("callTool maps a closed input to an allowlisted request", async () => {
-  let request;
-  const result = await callTool(definition, "items_list", { limit: 2 }, async (url, init) => {
-    request = { url: String(url), method: init.method };
-    return new Response(JSON.stringify({ items: [1, 2] }), { status: 200 });
-  });
-  assert.deepEqual(request, { url: "https://api.example.com/items?limit=2", method: "GET" });
-  assert.deepEqual(result, { items: [1, 2] });
-});
-
-test("rejects unknown inputs and writes by default", async () => {
-  await assert.rejects(
-    () => callTool(definition, "items_list", { token: "no" }),
-    /Unknown input property/,
-  );
-  const writable = {
-    ...definition,
-    tools: [{ ...definition.tools[0], name: "items_create", method: "POST", access: "write" }],
-  };
-  await assert.rejects(() => callTool(writable, "items_create", {}), /ZAIP_ALLOW_MCP_WRITES/);
-});

package/templates/.zaip-aios/templates/tools/runtime/fixtures/definition.json

@@ -1,17 +0,0 @@
-{
-  "id": "protocol-fixture",
-  "version": "0.1.0",
-  "baseUrl": "https://api.example.com",
-  "allowedHosts": ["api.example.com"],
-  "auth": { "env": [], "headers": [] },
-  "tools": [
-    {
-      "name": "items_list",
-      "description": "List items.",
-      "method": "GET",
-      "path": "/items",
-      "access": "read",
-      "inputSchema": { "type": "object", "additionalProperties": false, "properties": {} }
-    }
-  ]
-}

package/templates/.zaip-aios/templates/tools/runtime/runner.mjs

@@ -1,16 +0,0 @@
-import { readFile } from "node:fs/promises";
-import { resolve } from "node:path";
-import { callTool, doctor, runServer } from "./api-mcp-runtime.mjs";
-
-const [definitionPath, command = "serve", name, rawInput = "{}"] = process.argv.slice(2);
-if (!definitionPath)
-  throw new Error("Usage: runner.mjs <definition.json> [serve|doctor|call] [tool] [json]");
-const definition = JSON.parse(await readFile(resolve(definitionPath), "utf8"));
-if (command === "serve") await runServer(definition);
-else if (command === "doctor")
-  process.stdout.write(`${JSON.stringify(doctor(definition), null, 2)}\n`);
-else if (command === "call")
-  process.stdout.write(
-    `${JSON.stringify(await callTool(definition, name, JSON.parse(rawInput)), null, 2)}\n`,
-  );
-else throw new Error(`Unknown command: ${command}`);

package/templates/.zaip-aios/templates/tools/runtime/stdio.test.mjs

@@ -1,32 +0,0 @@
-import assert from "node:assert/strict";
-import { spawn } from "node:child_process";
-import { resolve } from "node:path";
-import test from "node:test";
-
-test("serves initialize and tools/list over newline-delimited STDIO", async () => {
-  const child = spawn(
-    process.execPath,
-    [
-      resolve(import.meta.dirname, "runner.mjs"),
-      resolve(import.meta.dirname, "fixtures/definition.json"),
-    ],
-    { stdio: ["pipe", "pipe", "pipe"] },
-  );
-  const output = [];
-  child.stdout.setEncoding("utf8");
-  child.stdout.on("data", (chunk) =>
-    output.push(...chunk.trim().split("\n").filter(Boolean).map(JSON.parse)),
-  );
-  child.stdin.write(
-    `${JSON.stringify({ jsonrpc: "2.0", id: 1, method: "initialize", params: { protocolVersion: "2025-06-18" } })}\n`,
-  );
-  child.stdin.write(
-    `${JSON.stringify({ jsonrpc: "2.0", id: 2, method: "tools/list", params: {} })}\n`,
-  );
-  child.stdin.end();
-  const code = await new Promise((done) => child.on("close", done));
-  assert.equal(code, 0);
-  assert.equal(output[0].result.serverInfo.name, "protocol-fixture");
-  assert.equal(output[1].result.tools[0].name, "items_list");
-  assert.equal(output[1].result.tools[0].annotations.readOnlyHint, true);
-});

package/templates/.zaip-aios/templates/tools/state.example.yaml

@@ -1,8 +0,0 @@
-schema_version: 1
-profile: default
-tools:
-  openai-docs:
-    installation: configured
-    authentication: not-required
-    runtime: enabled
-    health: unknown

package/templates/.zaip-aios/templates/zaip-aios/INDEX.md

@@ -1,26 +0,0 @@
-# Indice operacional ZAIP-AIOS
-
-Use esta pagina como roteador de baixo custo de tokens.
-
-| Necessidade | Leia |
-|---|---|
-| Comecar a usar o framework | `guides/01-primeiros-passos.md` |
-| Definir requisitos e aceite | `guides/02-requirements.md` |
-| Organizar uma entrega pequena | `guides/03-tasks.md` |
-| Planejar entrega com varias tarefas | `guides/04-specs.md` |
-| Planejar produto ou iniciativa | `guides/05-prds.md` |
-| Executar e registrar evidencias | `guides/06-execucao.md` |
-| Revisar e validar | `guides/07-revisao-e-validacao.md` |
-| Reduzir tokens e montar contexto | `guides/08-contexto-e-tokens.md` |
-| Coordenar agentes | `guides/09-agentes-e-squads.md` |
-| Tratar permissoes e segredos | `guides/10-seguranca.md` |
-| Examinar runs, custo e retrabalho | `guides/11-observabilidade-e-custos.md` |
-| Instalar, atualizar ou reverter | `guides/12-instalacao-e-upgrade.md` |
-| Aplicar praticas recomendadas | `guides/13-boas-praticas.md` |
-| Diagnosticar problemas | `guides/14-troubleshooting.md` |
-| Configurar MCPs, APIs e Codex | `guides/15-tools-e-codex.md` |
-| Entender status, Runs e reconciliação | `guides/16-lifecycle-e-reconciliacao.md` |
-| Escolher MCP ou API | `../tools/catalog.yaml` |
-
-Antes de agir, prevalecem `../config/project.yaml`, as Rules aplicaveis e os
-Requirements ativos. Leia records somente por ID explicito do ciclo de vida.

package/templates/.zaip-aios/templates/zaip-aios/README.md

@@ -1,13 +0,0 @@
-# ZAIP-AIOS Handbook
-
-Documentacao operacional local do ZAIP-AIOS para pessoas e agentes.
-
-## Leitura eficiente
-
-1. Leia primeiro apenas `INDEX.md`.
-2. Abra somente o guia relacionado ao trabalho atual.
-3. Para integracoes, consulte `.agents/tools/catalog.yaml` e depois um unico manifesto.
-4. Nao carregue toda esta pasta no contexto.
-
-`VERSION` informa a versao do handbook instalada. As regras canonicas continuam em
-`.agents/rules/zaip/`; este handbook explica como aplica-las, mas nao as substitui.

package/templates/.zaip-aios/templates/zaip-aios/VERSION

@@ -1 +0,0 @@
-1.0.0

package/templates/.zaip-aios/templates/zaip-aios/guides/01-primeiros-passos.md

@@ -1,10 +0,0 @@
-# Primeiros passos
-
-1. Leia `.agents/config/project.yaml` e `.agents/rules/zaip/core.md`.
-2. Consulte `.agents/projections/runtime/` para descobrir o estado atual.
-3. Classifique a entrada: Conversation, Task avulsa, SPEC ou PRD. Pergunta/análise read-only é Conversation e não cria Task.
-4. Carregue somente Rules, Requirements e skills aplicaveis.
-5. Defina aceite verificavel antes de editar.
-6. Antes de escrita persistente, inicie Task, Change, Execution e Run raiz do orquestrador; execute Sub-Runs, teste e registre evidencias no ciclo de vida ativo.
-
-Evite varrer `.agents/records/`: abra um record apenas quando possuir seu ID.

package/templates/.zaip-aios/templates/zaip-aios/guides/02-requirements.md

@@ -1,12 +0,0 @@
-# Requirements
-
-Use Requirement para uma obrigacao duravel e testavel.
-
-1. Descreva resultado e limite, nao a implementacao preferida.
-2. Crie criterios de aceite observaveis.
-3. Registre riscos, dependencias e casos negativos.
-4. Relacione cada criterio a teste ou evidencia.
-5. Versione mudancas sem apagar a intencao anterior.
-6. Promova somente depois de validar consistencia e rastreabilidade.
-
-Um bom criterio responde inequivocamente: passou ou falhou?

package/templates/.zaip-aios/templates/zaip-aios/guides/03-tasks.md

@@ -1,12 +0,0 @@
-# Tasks
-
-Use Task para uma entrega pequena, independente e com um resultado claro.
-
-1. Pedido avulso explícito de ação entra diretamente em Execução; somente preparação sem autorização de executar pode parar em Pronto para Executar.
-2. Declare objetivo, escopo e fora de escopo.
-3. Vincule Requirements aplicaveis.
-4. Liste arquivos ou componentes provaveis, sem congelar a solucao.
-5. Defina verificacoes proporcionais ao risco.
-6. Use uma Run raiz do orquestrador por tentativa, finalize os Sub-Runs de trabalho e execute o finalizador como ultimo filho.
-7. Antes de a Run terminar, mova a Task para completed, blocked, failed ou cancelled; nunca deixe executing/verifying.
-8. Retome blocked com `task resume`; trate failed com `task rework` na mesma Task. Completed/cancelled sao imutaveis.

package/templates/.zaip-aios/templates/zaip-aios/guides/04-specs.md

@@ -1,16 +0,0 @@
-# SPECs
-
-Use SPEC quando a entrega exige varias Tasks ou uma ordem de dependencia.
-
-1. Transforme o resultado desejado em capacidades verificaveis.
-2. Consulte `stack.profile` e `stack.overrides` em `.agents/config/project.yaml` e resolva `.zaip-aios/profiles/<stack.profile>.json` como stack padrao do projeto.
-3. Registre `stack_profile`, `stack_overrides`, `stack_description` curta e componentes com linguagem, runtime, frameworks, versoes exatas e fontes verificaveis no workspace.
-4. Divida em Tasks pequenas, cada uma com aceite proprio.
-5. Modele dependencias como DAG; evite sequencias artificiais.
-6. Identifique caminhos criticos, riscos e rollback.
-7. Mapeie cada Requirement para Tasks e evidencias.
-8. Valide a SPEC antes de iniciar execucao; bloqueie stack ausente, divergente ou sem versoes exatas e fontes existentes.
-9. Ao iniciar a primeira Task, mantenha a SPEC em Execucao entre todas as Runs filhas; resultado terminal de uma Task nao terminaliza a SPEC.
-10. Depois de todas as Tasks concluidas, rode verificacao e Evidence parentais antes de deliver.
-
-Uma SPEC planeja a entrega; nao autoriza mudancas externas por si so.

package/templates/.zaip-aios/templates/zaip-aios/guides/05-prds.md

@@ -1,13 +0,0 @@
-# PRDs
-
-Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
-
-1. Registre problema, publico, resultado e metricas.
-2. Delimite escopo, restricoes e nao objetivos.
-3. Mantenha o PRD agnostico de linguagem, framework, banco, infraestrutura e fornecedor; tecnologia imposta externamente entra como restricao de negocio, nao como desenho da solucao.
-4. Especifique requisitos funcionais e nao funcionais.
-5. Converta capacidades em SPECs independentes, onde a stack tecnica sera resolvida.
-6. Relacione riscos, rollout, observabilidade e rollback.
-7. Monte a DAG e confirme que todo aceite possui evidencia planejada.
-8. Mantenha PRD e SPECs selecionadas em Execucao enquanto restar trabalho; Runs filhas fecham Tasks, nao o macro.
-9. Conclua somente depois das Tasks, integracao, outcomes e gates parentais.

package/templates/.zaip-aios/templates/zaip-aios/guides/06-execucao.md

@@ -1,13 +0,0 @@
-# Execucao
-
-1. Confirme Task, Change, Execution, aceite e Run raiz do orquestrador.
-2. Antes da primeira mutacao persistente, confirme Task executing e Run raiz ativa no turno atual.
-3. Inspecione o diff e preserve alteracoes alheias.
-4. Use Sub-Runs para cada subagente; a Run raiz aguarda todos os descendentes ativos.
-5. Implemente o menor incremento coerente e rode verificacoes focadas.
-6. Registre decisoes consequenciais, evidencias e desvios.
-7. Depois dos demais descendentes, execute `zaip-agent-finalizer` como ultimo Sub-Run da Execution. Nenhum filho novo pode iniciar depois dele.
-8. Finalize a Run raiz com status tecnico e resultado terminal da Task separados.
-9. Execute os gates finais e documente rollback.
-
-Nao marque conclusao por esforco: conclua pelo resultado verificavel. Gate insuficiente ou finalizador ausente usa blocked; erro tecnico impeditivo usa failed; cancelamento exige pedido explicito.

package/templates/.zaip-aios/templates/zaip-aios/guides/07-revisao-e-validacao.md

@@ -1,8 +0,0 @@
-# Revisao e validacao
-
-1. Revise Requirements e criterios de aceite.
-2. Examine diff, limites arquiteturais e caminhos de erro.
-3. Rode testes focados e depois gates completos aplicaveis.
-4. Verifique seguranca, compatibilidade, documentacao e rollback.
-5. Classifique achados por impacto e cite evidencia concreta.
-6. Registre o resultado sem alterar implementacao em uma revisao read-only.

package/templates/.zaip-aios/templates/zaip-aios/guides/08-contexto-e-tokens.md

@@ -1,10 +0,0 @@
-# Contexto e tokens
-
-1. Comece por `project.yaml`, `core.md` e projections de runtime.
-2. Carregue somente a Rule, Requirement ou skill acionada.
-3. Prefira indices, resumos e busca direcionada a arquivos completos.
-4. Abra records apenas por lifecycle ID conhecido.
-5. Resuma fatos estaveis; preserve texto literal apenas quando normativo.
-6. Remova do contexto resultados superados e detalhes nao acionaveis.
-
-Para tools, leia `catalog.yaml`, escolha um ID e abra somente seu manifesto.

package/templates/.zaip-aios/templates/zaip-aios/guides/09-agentes-e-squads.md

@@ -1,8 +0,0 @@
-# Agentes e squads
-
-1. Delegue apenas subtarefas concretas e independentes.
-2. Dê a cada agente objetivo, limites, entradas e formato de saida.
-3. Evite dois agentes editando os mesmos arquivos.
-4. Centralize decisoes arquiteturais e integracao no agente responsavel.
-5. Exija evidencias, nao apenas declaracoes de conclusao.
-6. Use paralelismo somente quando reduzir caminho critico sem aumentar conflito.

package/templates/.zaip-aios/templates/zaip-aios/guides/10-seguranca.md

@@ -1,206 +0,0 @@
-# Segurança dos perfis Codex ZAIP-AIOS
-
-## Visão geral
-
-O ZAIP-AIOS oferece dois perfis atuais:
-
-| Perfil | Filesystem nativo | Rede de comandos | Uso recomendado |
-| --- | --- | --- | --- |
-| `zaip-aios-security` | Escrita na raiz física do repositório, incluindo `.git`, `.agents`, `.codex` e demais arquivos ocultos | Limitada a `github.com` | Trabalho normal e princípio de menor privilégio, incluindo deploy GitHub autorizado |
-| `zaip-aios-full-access` | Escrita em `C:\` inteiro no Windows, quando as permissões do sistema permitirem | Completa, todos os domínios | Correção de configuração, diagnóstico ou operação que realmente exija acesso fora do workspace |
-
-A permissão nativa determina o que o processo tecnicamente consegue alcançar. Ela não
-substitui autorização do usuário, regras do repositório, hooks, skills ou controles do
-sistema operacional.
-
-## `zaip-aios-security`
-
-### Acesso concedido
-
-O perfil restrito concede:
-
-- leitura dos caminhos mínimos necessários para executar ferramentas;
-- escrita em `~/.ssh` para reparar a configuração e a identidade SSH local;
-- escrita na raiz física absoluta deste repositório;
-- escrita em todos os descendentes do workspace, incluindo `.git`, `.agents`, `.codex` e demais arquivos ocultos;
-- rede de comandos limitada a `github.com` para operações Git/SSH autorizadas.
-
-Exemplo da definição efetiva:
-
-```toml
-default_permissions = "zaip-aios-security"
-
-[permissions.zaip-aios-security]
-description = "ZAIP workspace-only development with editable project control trees and GitHub-only command network access."
-
-[permissions.zaip-aios-security.filesystem]
-":minimal" = "read"
-"~/.ssh" = "write"
-
-[permissions.zaip-aios-security.filesystem."C:\\caminho\\absoluto\\do\\workspace"]
-"." = "write"
-".git" = "write"
-".agents" = "write"
-".codex" = "write"
-
-[permissions.zaip-aios-security.network]
-enabled = true
-mode = "limited"
-
-[permissions.zaip-aios-security.network.domains]
-"github.com" = "allow"
-```
-
-A tabela usa a raiz física em vez de `extends = ":workspace"` ou `:workspace_roots`.
-No sandbox elevado do Windows, esses dois modos aplicam negações especiais a `.agents` e
-`.codex`; uma regra `write` mais específica pode não reabri-las por causa da precedência das
-ACLs `DENY`. As entradas explícitas acima materializam o conjunto correto de capabilities,
-mantêm a escrita limitada ao repositório — inclusive em `.git` — e não concedem escrita ao restante de `C:\`, ao perfil do
-usuário, a outros repositórios ou ao sistema operacional.
-
-### Segurança adicional
-
-`zaip-aios-security` possui a proteção mais forte porque os limites principais são aplicados
-pelo sandbox nativo:
-
-- uma tentativa de escrita fora do workspace é negada mesmo que uma instrução ou ferramenta
-  peça essa operação;
-- comandos alcançam apenas `github.com`; outros destinos permanecem negados;
-- `~/.ssh` pode ser alterado por fluxos Git ou de configuração explicitamente autorizados;
-- o impacto máximo de uma edição comum fica contido no repositório;
-- todas as camadas ZAIP descritas abaixo continuam ativas.
-
-Esse perfil deve ser o padrão para desenvolvimento, revisão, testes, manutenção normal e deploy GitHub autorizado quando a escrita na identidade SSH local for necessária. A escrita em `~/.ssh` e o egress para `github.com` ampliam o impacto potencial; nunca altere chaves, credenciais ou remotos sem autorização explícita.
-
-## `zaip-aios-full-access`
-
-### Acesso concedido
-
-No Windows, o perfil de acesso completo concede escrita em `C:\` inteiro e rede completa:
-
-```toml
-default_permissions = "zaip-aios-full-access"
-
-[permissions.zaip-aios-full-access.filesystem]
-":root" = "write"
-
-[permissions.zaip-aios-full-access.network]
-enabled = true
-mode = "full"
-
-[permissions.zaip-aios-full-access.network.domains]
-"*" = "allow"
-```
-
-A configuração pode representar a raiz como `:root` ou `C:\\`. Neste ambiente, isso
-inclui tecnicamente:
-
-- o workspace e todos os seus arquivos;
-- `.agents`, `.codex` e `.git`;
-- outros repositórios em `C:\`;
-- o perfil do usuário e seus arquivos;
-- diretórios de aplicações e do sistema;
-- qualquer destino de rede alcançável pelo host.
-
-O acesso continua sujeito às ACLs do Windows, políticas corporativas, arquivos em uso e
-privilégios da conta. O perfil não transforma o processo em administrador nem garante
-alteração de todo arquivo.
-
-### Riscos residuais
-
-`zaip-aios-full-access` continua sendo um perfil de maior risco. Um comando incorreto,
-conteúdo malicioso, dependência comprometida ou erro de escopo pode tentar:
-
-- alterar ou excluir arquivos fora do projeto;
-- modificar outros repositórios;
-- acessar dados do usuário;
-- executar operações destrutivas no sistema;
-- enviar dados pela rede;
-- ampliar o impacto de uma falha de supply chain.
-
-Ele deve ser ativado somente quando o perfil restrito não consegue executar uma operação
-legítima e explicitamente autorizada. Após a correção, volte para `zaip-aios-security`.
-
-## Camadas que reduzem o risco do full access
-
-O acesso completo é mitigado por defesa em profundidade, mas nenhuma camada torna
-`zaip-aios-full-access` equivalente ao perfil restrito:
-
-1. **Autorização explícita do usuário:** mudanças externas, destrutivas, publicação, deploy,
-   gasto e mutações remotas exigem pedido explícito no turno atual.
-2. **Escopo do repositório:** `AGENTS.md`, Rules e skills limitam o trabalho ao objetivo e
-   proíbem inferir autoridade adicional a partir do acesso técnico.
-3. **Hook `PreToolUse`:** valida comandos e patches antes da execução; bloqueia escapes do
-   repositório, referências diretas a segredos, elevação, persistência de sistema, firewall,
-   antivírus, serviços, Git destrutivo, banco destrutivo e clientes remotos não autorizados.
-4. **Regras `forbidden`:** arquivos em `.codex/rules/` negam classes perigosas de comandos
-   mesmo quando o sandbox permitiria executá-las.
-5. **Política GitHub delimitada:** deploy e push seguem preflight, branch e remoto explícitos;
-   force-push, exclusão remota e publicação não solicitada permanecem proibidos.
-6. **Proteção de segredos:** tokens, chaves privadas, credenciais e valores de ambiente não
-   podem ser impressos, copiados, registrados em Runs nem incluídos em commits.
-7. **Lifecycle e telemetria sanitizada:** Runs registram atribuição, uso e resultado sem
-   autorizar ações nem persistir segredos.
-8. **Subagentes com menor privilégio:** agentes de revisão e auditoria permanecem read-only;
-   builders e integradores recebem escopos limitados.
-9. **Controles do sistema operacional:** ACLs, conta Windows, arquivos em uso e políticas do
-   host continuam sendo a última barreira técnica.
-
-Essas camadas reduzem probabilidade e impacto, mas podem conter bugs ou lacunas. Os limites
-nativos de `zaip-aios-security` oferecem proteção adicional ao negar escrita fora do workspace
-e egress para destinos diferentes de `github.com` antes que a operação alcance o sistema ou a rede.
-
-## Escolha do perfil
-
-Use `zaip-aios-security` quando:
-
-- todo o trabalho deve permanecer neste workspace;
-- `.agents` e `.codex` precisam ser editáveis;
-- comandos precisam, no máximo, alcançar `github.com` para operações Git/SSH autorizadas;
-- menor privilégio é desejado.
-
-Use `zaip-aios-full-access` apenas quando:
-
-- for necessário corrigir a própria configuração de permissões;
-- uma operação autorizada precisar de um caminho fora do workspace;
-- o bloqueio do perfil restrito tiver sido diagnosticado e não houver alternativa limitada.
-
-Não use full access apenas para evitar investigar uma negação.
-
-## Validação obrigatória
-
-Após alterar qualquer perfil:
-
-1. Confirme que `default_permissions` seleciona exatamente o perfil desejado.
-2. Confirme que não existe `sandbox_mode` em outra configuração carregada.
-3. Reinicie completamente o Codex.
-4. Com `zaip-aios-security`, valide escrita no workspace, em `.agents` e em `.codex`.
-5. Quando uma operação Git estiver autorizada, confirme que `.git` aceita a alteração de índice necessária, sem ampliar o acesso fora do repositório.
-6. Confirme que escrita fora do workspace é negada sem criar arquivo externo.
-7. Confirme que Git/SSH alcança `github.com` somente após autorização de deploy e que outros destinos continuam negados.
-8. Execute uma captura ZAIP e confirme `run.started`, `usage.recorded` e `run.finished`.
-9. Com full access, confirme a seleção do perfil sem realizar probes destrutivos ou gravar em
-   caminhos externos apenas para demonstrar alcance.
-
-O sandbox e as ACLs são materializados na inicialização; o teste funcional precisa ocorrer
-em uma nova sessão.
-
-Se uma versão anterior com `:workspace` ou `:workspace_roots` já tiver sido executada e o
-reinício continuar negando `.agents`/`.codex`, feche todas as sessões Codex, faça backup de
-`~/.codex/cap_sid`, mova somente o arquivo ativo para fora desse caminho e reinicie o Codex.
-O runtime criará novos capability SIDs; os `DENY` antigos ficarão inertes por não pertencerem
-ao novo token. Não edite ACLs manualmente e preserve o backup para rollback.
-
-## Arquivos da política
-
-| Arquivo | Papel |
-| --- | --- |
-| `~/.codex/config.toml` | seleção e definição efetiva dos perfis |
-| `.codex/config.toml` | projeção versionada dos perfis e hooks |
-| `.codex/zaip-aios-security.config.toml` | configuração dedicada do perfil restrito |
-| `.codex/zaip-aios-full-access.config.toml` | configuração dedicada do perfil completo |
-| `.agents/skills/zaip-skill-security/SKILL.md` | avaliação dos riscos e controles |
-| `.agents/skills/zaip-skill-setup/SKILL.md` | instalação, correção e validação dos perfis |
-| `.codex/hooks/zaip-pre-tool-use.mjs` | guarda adicional de comandos |
-| `.codex/rules/` | decisões determinísticas de comandos permitidos e proibidos |
-| este guia | contrato operacional e comparação dos perfis |

package/templates/.zaip-aios/templates/zaip-aios/guides/11-observabilidade-e-custos.md

@@ -1,10 +0,0 @@
-# Observabilidade e custos
-
-1. Selecione o Run pelo ID.
-2. Verifique duracao, tokens, custo, retries e retrabalho.
-3. Compare aceite planejado com evidencia produzida.
-4. Identifique gates lentos, contexto excessivo e chamadas repetidas.
-5. Agregue tendencias sem expor prompts ou segredos sensiveis.
-6. Converta achados recorrentes em Rule, Requirement ou melhoria de skill.
-
-Run e o envelope da chamada do `zaip-agent-orchestrator`; `parent_run_id` nulo identifica esse nivel. Sub-Run e a chamada de qualquer subagente e possui `parent_run_id`. Ambas fixam modelo e effort e agregam Calls, segmentos de uso, tokens e custo. Calls nao possuem tela ou lifecycle proprio. Operacao e Monitor de Custos apresentam “Chamadas do agente orquestrador” e “Chamadas de subagentes”; a Execution soma as duas categorias, finalizadores e Calls sem dupla contagem. Cada segmento de uso possui uma chave de origem e so pode ser atribuido uma vez; uma correcao de duplicidade registra supersessao e preserva o evento historico. Inspecione `run_purpose`, pai e `agent_name`; agentes do catalogo usam `zaip-agent-*`. Diferencie status tecnico da chamada de agente e resultado terminal da Task. Reconcilie lifecycle globalmente apenas por comando humano explicito ou pelo popup confirmado; isso nao ocorre em cada turno nem ao abrir o dashboard.

package/templates/.zaip-aios/templates/zaip-aios/guides/12-instalacao-e-upgrade.md

@@ -1,10 +0,0 @@
-# Instalacao e upgrade
-
-1. Verifique versao atual e estado limpo ou conscientemente preservado.
-2. Execute doctor/integrity antes da mudanca.
-3. Faça dry-run da instalacao, migracao ou upgrade.
-4. Revise arquivos gerenciados, publicos e preservados.
-5. Aplique, valide adapters e rode gates.
-6. Teste rollback e confirme a versao final.
-
-`framework.lock.yaml` e relevante neste fluxo; nao o carregue no trabalho comum.

package/templates/.zaip-aios/templates/zaip-aios/guides/13-boas-praticas.md

@@ -1,12 +0,0 @@
-# Boas praticas
-
-- Comece pelo resultado e aceite, nao pela ferramenta.
-- Mantenha dominio independente de infraestrutura.
-- Faça mudancas pequenas, reversiveis e rastreaveis.
-- Valide cedo com testes deterministas e focados.
-- Prefira configuracao explicita a convencoes ocultas.
-- Leia contexto sob demanda e preserve o budget de tokens.
-- Trate documentacao, observabilidade e rollback como parte da entrega.
-- Nunca termine a Run raiz sem o Sub-Run finalizador ou com Task em executing/verifying.
-- Nao terminalize SPEC/PRD por causa do resultado isolado de uma Task filha.
-- Prefira reconciliacao manual sob demanda; hooks de escrita fazem checagem local sem varredura global.

package/templates/.zaip-aios/templates/zaip-aios/guides/14-troubleshooting.md

@@ -1,12 +0,0 @@
-# Troubleshooting
-
-1. Reproduza o problema com o menor comando possivel.
-2. Leia a mensagem completa e identifique o primeiro erro causal.
-3. Rode doctor, validadores focados e `git diff --check`.
-4. Confira versoes, paths, encoding, variaveis e arquivos gerenciados.
-5. Compare com projections de runtime, sem varrer records.
-6. Corrija a causa, repita a reproducao e depois os gates completos.
-
-Se uma Task estiver presa em executing/verifying, use o popup Reconciliar. O reparo aceita `task_complete` exato, marca Run orfa apos dez minutos como failed e usa blocked quando faltam gates; nunca infere cancelamento. Nao habilite reconciliacao automatica por turno ou na abertura do dashboard.
-
-Se o problema for de instalacao ou integridade, consulte `framework.lock.yaml`.

package/templates/.zaip-aios/templates/zaip-aios/guides/15-tools-e-codex.md

@@ -1,25 +0,0 @@
-# Tools e setup do Codex
-
-1. Peça ao agente para listar ou ativar uma tool; ele usa `$zaip-skill-tool-setup`.
-2. A skill lê somente catálogo e manifesto aplicável.
-3. MCP confiável é registrado desabilitado em `.codex/config.toml` e validado antes da ativação.
-4. API sem MCP confiável aciona `$zaip-skill-api-to-mcp` para gerar um adaptador seguro.
-5. Secrets nunca são coladas no chat; nomes ficam em `.agents/.env.example` e valores em armazenamento local ignorado.
-6. Alterações de configuração devem ser reversíveis e preservar preferências existentes.
-
-Ative por padrão apenas integrações públicas, read-only e sem autenticação, como documentação oficial. Browser/Playwright deve ser opt-in do perfil de desenvolvimento, pois inicia processos e amplia a superfície operacional.
-
-## MCP local gerado de API
-
-1. Modele um `adapter.yaml` a partir de documentação oficial; use o exemplo da skill API-to-MCP.
-2. Execute `scaffold-local-mcp.mjs` para gerar `definition.json`, `server.mjs` e `cli.mjs`.
-3. Rode `node .agents/tools/servers/<id>/cli.mjs doctor`.
-4. Faça chamadas read-only com `cli.mjs call <tool> '<json>'`.
-5. Gere um preview do Codex com `configure-local-mcp.mjs <id>`.
-6. Revise e aplique com `--write`; use `--enable` somente quando o doctor estiver pronto.
-
-O servidor usa STDIO, não abre porta e não exige deploy. Escritas ficam bloqueadas sem aprovação e `ZAIP_ALLOW_MCP_WRITES=1`.
-
-## Documentacao OpenAI
-
-O perfil default habilita `openaiDeveloperDocs` em `.codex/config.toml`, sem credencial e em modo read-only. Perguntas sobre OpenAI API, modelos, SDKs, Codex ou MCP devem acionar `$zaip-skill-openai-docs`, pesquisar o MCP oficial e citar a pagina consultada.

package/templates/.zaip-aios/templates/zaip-aios/guides/16-lifecycle-e-reconciliacao.md

@@ -1,47 +0,0 @@
-# Lifecycle e reconciliacao
-
-## Entradas
-
-- Conversation: pergunta, feedback ou analise read-only; cria Run intake e nenhuma Task.
-- Task avulsa: resultado independente. Pedido de acao entra em Execucao antes da primeira escrita; pedido apenas de preparacao pode parar em Pronto para Executar.
-- SPEC: planejamento tecnico de multiplas Tasks; draft fica em Planejamento.
-- PRD: definicao de produto; draft fica em Definicao.
-
-## Colunas
-
-| Coluna | Entidades |
-|---|---|
-| Definicao | somente PRD draft |
-| Planejamento | somente SPEC draft |
-| Pronto para Executar | PRD/SPEC ready e Task avulsa nao iniciada |
-| Execucao | Task executing e SPEC/PRD active |
-| Verificacao | Task verifying ou macro nos gates parentais |
-| Finais | completed/delivered, blocked, failed ou cancelled |
-
-## Execution, Runs, Sub-Runs e Calls
-
-- Execution coordena a DAG de uma ou mais Tasks.
-- Run e a chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id` nulo.
-- Sub-Run e cada chamada de subagente; possui `parent_run_id` e compartilha o mesmo ledger `RUN-*`.
-- Novas gravacoes usam somente `run_role: intake|orchestrator|subagent`; `owner|contributor` sao valores historicos aceitos apenas na leitura e normalizados imediatamente.
-- `run_purpose` distingue `orchestration`, `execution`, `review`, `audit` e `finalization`.
-- cada Run/Sub-Run fixa agente, modelo e effort; mudanca deliberada abre outra chamada de agente.
-- Calls e ferramentas sao eventos internos; quantidade, tokens e custo ficam agregados na Run/Sub-Run, sem tela propria.
-
-O ultimo filho de qualquer Execution e sempre o `zaip-agent-finalizer`. Ele aguarda todos os outros descendentes, cria uma barreira contra filhos posteriores e retorna uma decisao terminal restrita para a CLI aplicar. Toda Execution exige antes ao menos um executor elegivel pelas capacidades do catalogo. Status tecnico da chamada de agente e resultado do trabalho sao independentes.
-
-`blocked` e retomavel com `task resume`; `failed` exige `task rework` na mesma Task e nova tentativa. `completed` e `cancelled` sao imutaveis. Interromper geracao bloqueia; cancelar a Task explicitamente cancela.
-
-## SPEC e PRD
-
-Ao iniciar a primeira Task filha, os pais ficam active/Execucao e permanecem assim entre Runs. Task bloqueada ou falhada nao bloqueia automaticamente o pai. Depois que todas as Tasks concluem, SPEC/PRD entram em verificacao parental; apenas gates de integracao, Acceptance Criteria, outcomes e Evidence entregam o macro.
-
-## Reconciliacao
-
-O popup Reconciliar chama `run reconcile --open` somente depois da confirmacao humana. Nao existe varredura ao abrir o dashboard, por turno ou por intervalo.
-
-O reparo e idempotente: `task_complete` local exato permite tentar conclusao; gate insuficiente usa blocked; Run sem invocacao ativa por dez minutos usa failed; cancelled nunca e inferido. Projecoes exibem o status persistido e nao revivem Task terminal por atividade local obsoleta.
-
-## Mutacoes
-
-Codigo, documentacao e configuracao exigem Task materializada e Run raiz ativa antes da escrita. Sao isentos deploy/publicacao Git sem mudanca de produto, records/projections/telemetria ZAIP, metadados `.git`, caches, builds, testes e temporarios descartaveis. O hook pre-write faz checagem local do turno, sem tokens e sem reconciliacao global.