@zaip-ai/cli 1.0.6 → 1.0.7

package/templates/.agents/design/apps/catalog/src/styles/components.css

@@ -1,8 +1,8 @@
 .card {
-  border: 1px solid #dbe4ef;
+  border: 1px solid var(--border);
   border-radius: 24px;
   padding: 24px;
-  background: #ffffff;
+  background: var(--surface);
   box-shadow: 0 18px 48px rgba(15, 23, 42, 0.08);
 }
 .card-accent {
@@ -115,6 +115,20 @@
 .form-grid {
   row-gap: 24px;
 }
+.filter-form {
+  display: grid;
+  grid-template-columns: minmax(160px, 0.65fr) minmax(220px, 1fr) auto auto;
+  align-items: end;
+  gap: 12px;
+  margin-bottom: 18px;
+  border: 1px solid var(--border);
+  border-radius: 24px;
+  padding: 18px;
+  background: var(--surface);
+}
+.filter-form .button {
+  white-space: nowrap;
+}
 
 .metric-grid {
   display: grid;
@@ -147,7 +161,7 @@ table {
 th,
 td {
   padding: 16px 20px;
-  border-bottom: 1px solid #dbe4ef;
+  border-bottom: 1px solid var(--border);
   text-align: left;
 }
 th {
@@ -191,6 +205,143 @@ tbody tr:last-child td {
   color: #006b91;
   font-size: 2rem;
 }
+.chart-heading {
+  display: flex;
+  align-items: flex-start;
+  justify-content: space-between;
+  gap: 18px;
+}
+.chart-heading strong {
+  display: block;
+  margin-top: 6px;
+}
+.bar-chart {
+  display: grid;
+  height: 220px;
+  grid-template-columns: repeat(6, minmax(20px, 1fr));
+  align-items: end;
+  gap: clamp(8px, 2vw, 20px);
+  margin-top: 28px;
+  border-bottom: 1px solid var(--border);
+  padding: 18px 18px 0;
+  background: linear-gradient(to top, var(--primary-wash), transparent 70%);
+}
+.bar-chart-column {
+  display: flex;
+  height: 100%;
+  align-items: end;
+}
+.bar-chart-column i {
+  width: 100%;
+  height: var(--bar-size);
+  min-height: 12px;
+  border-radius: 12px 12px 2px 2px;
+  background: linear-gradient(
+    180deg,
+    color-mix(in srgb, var(--primary) 48%, white) 0%,
+    var(--primary) 55%,
+    var(--primary-strong) 100%
+  );
+}
+.chart-caption {
+  margin-bottom: 0;
+  font-size: 0.88rem;
+}
+.dialog-backdrop {
+  position: fixed;
+  z-index: 50;
+  inset: 0;
+  display: grid;
+  place-items: center;
+  padding: 20px;
+  background: var(--overlay);
+  backdrop-filter: blur(8px);
+}
+.dialog-panel {
+  width: min(540px, 100%);
+  border: 1px solid var(--border);
+  border-radius: 24px;
+  padding: 24px;
+  background: var(--surface);
+  box-shadow: 0 24px 72px var(--dialog-shadow);
+}
+.dialog-panel header,
+.dialog-panel footer {
+  display: flex;
+  align-items: flex-start;
+  justify-content: space-between;
+  gap: 16px;
+}
+.dialog-panel h3,
+.state-panel h3 {
+  margin: 6px 0 0;
+}
+.dialog-panel footer {
+  justify-content: flex-end;
+  margin-top: 24px;
+}
+.dialog-close {
+  display: grid;
+  width: 44px;
+  height: 44px;
+  place-items: center;
+  border: 1px solid var(--border);
+  border-radius: 999px;
+  background: var(--surface);
+  color: var(--text);
+  font-size: 1.35rem;
+  cursor: pointer;
+}
+.state-grid {
+  display: grid;
+  grid-template-columns: repeat(3, minmax(0, 1fr));
+  gap: 18px;
+}
+.state-grid > .card {
+  height: 100%;
+}
+.state-panel {
+  display: flex;
+  align-items: flex-start;
+  gap: 14px;
+}
+.state-panel p {
+  margin: 8px 0 0;
+  color: var(--text-muted);
+  line-height: 1.55;
+}
+.state-error {
+  color: var(--error-text);
+}
+.state-error .button {
+  margin-top: 18px;
+}
+.state-symbol,
+.loading-spinner {
+  flex: 0 0 auto;
+}
+.state-symbol {
+  display: grid;
+  width: 42px;
+  height: 42px;
+  place-items: center;
+  border-radius: 16px;
+  background: var(--error-surface);
+  font-weight: 800;
+}
+.loading-spinner {
+  width: 34px;
+  height: 34px;
+  border: 3px solid var(--border);
+  border-top-color: var(--primary);
+  border-radius: 50%;
+  animation: catalog-spin 900ms linear infinite;
+}
+@keyframes catalog-spin {
+  to {
+    transform: rotate(360deg);
+  }
+}
 
 .theme-dark .card,
 .theme-dark .table-wrap {
@@ -219,6 +370,13 @@ tbody tr:last-child td {
   background: #0f172a;
   color: var(--text);
 }
+.theme-dark .filter-form,
+.theme-dark .dialog-panel,
+.theme-dark .dialog-close {
+  border-color: var(--border);
+  background: var(--surface);
+  color: var(--text);
+}
 .theme-dark .button-secondary {
   color: #7dd3fc;
 }
@@ -226,3 +384,46 @@ tbody tr:last-child td {
 .theme-dark td {
   border-color: var(--border);
 }
+.theme-dark .bar-chart {
+  border-color: var(--border);
+}
+.theme-dark .state-panel p {
+  color: var(--text-muted);
+}
+
+@media (max-width: 900px) {
+  .filter-form {
+    grid-template-columns: repeat(2, minmax(0, 1fr));
+  }
+  .filter-form .button {
+    width: 100%;
+  }
+  .state-grid {
+    grid-template-columns: 1fr;
+  }
+}
+
+@media (max-width: 560px) {
+  .filter-form {
+    grid-template-columns: 1fr;
+  }
+  .bar-chart {
+    height: 170px;
+    gap: 7px;
+    padding-inline: 8px;
+  }
+  .dialog-panel footer {
+    align-items: stretch;
+    flex-direction: column-reverse;
+  }
+  .dialog-panel footer .button {
+    width: 100%;
+  }
+}
+
+@media (prefers-reduced-motion: reduce) {
+  .loading-spinner {
+    animation: none;
+    border-color: var(--primary);
+  }
+}

package/templates/.agents/design/apps/catalog/src/styles/design-system.css

@@ -109,6 +109,8 @@
   --text-secondary: #cbd5e1;
   --text-muted: #94a3b8;
   --border: rgba(255, 255, 255, 0.12);
+  --error-surface: rgba(220, 38, 38, 0.14);
+  --error-text: #fecaca;
 }
 .theme-dark .catalog-section,
 .theme-dark .type-sample {

package/templates/.agents/design/apps/catalog/src/styles.css

@@ -28,6 +28,11 @@
   --error: #dc2626;
   --error-ink: #b91c1c;
   --focus: #00b0f0;
+  --overlay: rgba(10, 14, 23, 0.72);
+  --dialog-shadow: rgba(15, 23, 42, 0.22);
+  --primary-wash: rgba(0, 176, 240, 0.05);
+  --error-surface: #fef2f2;
+  --error-text: var(--error-ink);
   font-synthesis: none;
   text-rendering: optimizeLegibility;
 }

package/templates/.agents/design/tokens.json

@@ -24,7 +24,15 @@
     "surface-muted": "#111827",
     "text": "#f1f5f9",
     "text-muted": "#94a3b8",
-    "border": "rgba(255,255,255,0.12)"
+    "border": "rgba(255,255,255,0.12)",
+    "error-surface": "rgba(220,38,38,0.14)",
+    "error-text": "#fecaca"
+  },
+  "effects": {
+    "overlay": "rgba(10,14,23,0.72)",
+    "dialog-shadow": "rgba(15,23,42,0.22)",
+    "primary-wash": "rgba(0,176,240,0.05)",
+    "error-surface": "#fef2f2"
   },
   "neutral": {
     "text-primary": "#0f172a",

package/templates/.agents/requirements/autonomous-assurance.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-AUTONOMOUS-ASSURANCE
 area: autonomous-assurance
 title: Garantia adaptativa e execução autônoma
 status: active
-version: 1
+version: 2
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Garantia adaptativa e execução autônoma
@@ -15,17 +15,17 @@ source_release: "1.0.6"
 
 Uma Task avulsa deve provar todos os Acceptance Criteria com profundidade proporcional ao risco, sem criar validação cerimonial.
 
-- `AC-ASSURE-001-01`: risco `lite` exige exatamente uma validação tipada aprovada e uma Evidence tipada aprovada; ambas podem cobrir vários ACs, mas a união precisa cobrir todos os ACs da Task.
-- `AC-ASSURE-001-02`: risco `standard` exige exatamente duas validações e duas Evidences no perfil base ou exatamente três de cada no perfil elevado; os artefatos usam modalidades distintas e incluem teste executado.
-- `AC-ASSURE-001-03`: `standard_depth: auto` seleciona o perfil elevado quando a Task possui mais de um write scope; `base` e `elevated` permitem configuração explícita.
-- `AC-ASSURE-001-04`: risco `critical` exige no mínimo três validações, Evidence dedicada por AC, teste, quality review independente, discriminação por mutação, rollback comprovado e artefatos frescos no commit final.
+- `AC-ASSURE-001-01`: risco `lite` exige ao menos uma validação tipada aprovada e uma Evidence tipada aprovada; extras são aceitos e a união cobre todos os ACs. Teste só é obrigatório quando lógica ou regressão forem declaradas.
+- `AC-ASSURE-001-02`: risco `standard` exige ao menos duas validações (três no perfil elevado), modalidades distintas, teste executado e ao menos uma Evidence consolidada cobrindo os ACs; não impõe teto de artefatos nem quota de Evidences.
+- `AC-ASSURE-001-03`: `standard_depth: auto` seleciona perfil por sinais persistidos de risco/escopo de verificação, sem inferir criticidade pela quantidade de arquivos ou write scopes; `base` e `elevated` permitem configuração explícita.
+- `AC-ASSURE-001-04`: risco `critical` exige no mínimo três validações e quality review independente. Mutação é exigida para segurança/dados críticos; lógica determinística pode escolher mutação manualmente como modalidade adicional. Rollback é exigido para migração, irreversibilidade ou rollback não trivial; commit final para produção, distribuição, migração ou ação externa; Evidence dedicada por AC somente para segurança ou migração enquanto não houver sinal persistido para outro controle.
 - `AC-ASSURE-001-05`: uma Task sensível a segurança, migração, irreversibilidade ou múltiplos domínios não pode usar `lite` para contornar controles críticos.
 
 ## REQ-ASSURE-002 — Garantia parental para SPEC e PRD
 
 Entregar uma SPEC ou PRD deve exigir prova no nível do produto planejado, além da soma dos testes das Tasks descendentes.
 
-- `AC-ASSURE-002-01`: SPEC e PRD exigem matriz completa de ACs, pelo menos três validações parentais e pelo menos três Evidences parentais aprovadas.
+- `AC-ASSURE-002-01`: SPEC e PRD exigem matriz completa de ACs, pelo menos três validações parentais nas modalidades integração/cross-SPEC E2E, spec review e quality review, e pelo menos três Evidences parentais aprovadas. PRD mantém Evidence por outcome, sem ativar mutação, rollback ou Evidence universal por AC sem sinal parental persistido.
 - `AC-ASSURE-002-02`: SPEC exige integração, spec review e quality review; PRD exige cross-SPEC E2E, spec review e quality review.
 - `AC-ASSURE-002-03`: a revisão parental é feita por verificador diferente do autor e por Run diferente.
 - `AC-ASSURE-002-04`: todas as validações e Evidences parentais referenciam o commit final esperado; artefato de commit anterior não prova a entrega atual.
@@ -36,10 +36,10 @@ Entregar uma SPEC ou PRD deve exigir prova no nível do produto planejado, além
 O framework deve preservar execução manual como padrão e permitir autonomia somente por configuração explícita.
 
 - `AC-AUTO-001-01`: ausência de `execution` ou `execution.runtime: manual` materializa o trabalho sem invocar provider; `autonomous` exige provider, modelo, lease e paralelismo limitados.
-- `AC-AUTO-001-02`: o paralelismo efetivo é o menor limite entre projeto, plano, provider e squad; locks de DAG e write scopes continuam soberanos.
+- `AC-AUTO-001-02`: o paralelismo efetivo é o menor limite entre projeto, plano, provider e squad. SPECs independentes podem usar Executions-filhas isoladas sob coordenação do PRD, mas locks globais de DAG e write scopes, além do orçamento global, continuam soberanos; SPECs sem elegibilidade permanecem na DAG global.
 - `AC-AUTO-001-03`: cada Task autônoma executa em Git worktree registrada, parte de raiz limpa, produz commit final, altera somente write scopes autorizados e aborta merge conflitante sem deixar merge parcial.
 - `AC-AUTO-001-04`: processos usam command allowlist, `shell: false`, diretório validado, ambiente mínimo allowlisted, limite de linha/stderr, timeout, cancelamento e budget de ferramentas/output.
-- `AC-AUTO-001-05`: checkpoints opacos de Codex ou Claude ficam somente em `.zaip-aios/local-data`, são retomáveis e removidos ao terminar; estado governado usa compare-and-swap.
+- `AC-AUTO-001-05`: checkpoints opacos de Codex ou Claude ficam somente em `.local`, são retomáveis e removidos ao terminar; estado governado usa compare-and-swap.
 - `AC-AUTO-001-06`: Tasks `lite` têm uma tentativa; `standard` e `critical` têm no máximo três tentativas de desenvolvimento/reparo, sem loops ilimitados.
 - `AC-AUTO-001-07`: trabalho `critical` usa contexto fresco por Task e verificador independente; SPEC/PRD também exigem verificador independente mesmo quando suas Tasks são `lite`.
 
@@ -60,4 +60,3 @@ O release deve falhar de modo discriminante quando código, distribuição ou ev
 - `AC-QUALITY-001-02`: cobertura usa baseline versionada e ratchet `max(piso, baseline anterior)` com pisos de 80% para lines/functions/statements e 75% para branches.
 - `AC-QUALITY-001-03`: baseline observada abaixo do piso pode ser registrada para transparência, mas não reduz o gate nem torna a release aprovada.
 - `AC-QUALITY-001-04`: release verifica paridade entre fonte canônica, template público e artefato distribuído, além de smoke/cleanroom sobre o candidato exato.
-

package/templates/.agents/requirements/comparative-audit.md

@@ -0,0 +1,22 @@
+---
+schema_version: 2
+id: REQUIREMENTS-COMPARATIVE-AUDIT
+area: comparative-audit
+title: Auditoria comparativa e plano de evolução
+status: active
+version: 1
+source_change: null
+source_release: "1.0.7"
+---
+
+# Auditoria comparativa e plano de evolução
+
+## REQ-AUDIT-001 — Síntese comparativa rastreável
+
+A auditoria comparativa deve distinguir evidência observada, avaliação histórica e recomendação, preservando a proposta Git-native e Codex-first.
+
+- `AC-AUDIT-01`: o documento apresenta dez tópicos de comparação, a definição de cada tópico e uma nota de 0–10 para ZAIP-AIOS com fonte explícita.
+- `AC-AUDIT-02`: cada framework ou família previamente auditado aparece na síntese, sem inventar nota quantitativa quando a rubrica não for equivalente.
+- `AC-AUDIT-03`: o diagnóstico diferencia forças, fraquezas, limitações da evidência e melhorias recomendadas.
+- `AC-AUDIT-04`: as recomendações preservam Git-native, Codex-first e compatibilidade por adapters para Claude, Antigravity e outros hosts.
+- `AC-AUDIT-05`: o PRD permanece em `draft`, possui ao menos uma SPEC filha em `draft` e não cria plano executável, Change ou promoção de release.

package/templates/.agents/requirements/context-engine.md

@@ -6,7 +6,7 @@ title: Contexto mínimo, seguro e navegável
 status: active
 version: 8
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Context engine
@@ -25,19 +25,19 @@ Agentes devem construir contexto começando por configuração, Rule central, ar
 
 Rules do framework e Rules específicas do projeto devem permanecer separadas, navegáveis e sem sobrescrita implícita.
 
-- `AC-CONTEXT-002-01`: Rules fornecidas pelo ZAIP existem somente em `.agents/rules/zaip/`, são registradas no `framework.lock.yaml` e nenhum arquivo de Rule existe diretamente em `.agents/rules/`.
+- `AC-CONTEXT-002-01`: Rules fornecidas pelo ZAIP existem diretamente em `.agents/rules/`, são registradas no `framework.lock.yaml` e não usam uma subpasta de namespace.
 - `AC-CONTEXT-002-02`: Rules específicas existem somente em `.agents/rules/project/`, são preservadas por setup/upgrade e não entram no lock nem nos templates ou releases públicos.
 - `AC-CONTEXT-002-03`: setup, doctor, migração e context rejeitam ownership inválido e IDs duplicados; upgrades relocam Rules planas intactas e bloqueiam divergências antes de escrever.
 
 ## REQ-CONTEXT-003 — Navegação escalável
 
-Coleções de trabalho devem ser navegadas por projeções locais descartáveis antes da leitura pontual do conteúdo Git-native.
+Coleções de trabalho devem ser navegadas pelos manifests canônicos compactos antes da leitura pontual do conteúdo Git-native.
 
 - `AC-CONTEXT-003-01`: listagens aceitam status, período, relação, limite e continuação estável, com limite padrão de 20 e máximo de 200 por página.
 - `AC-CONTEXT-003-02`: listagens de PRD, SPEC e Task omitem o PreparedPlan completo e retornam somente resumo de preparação.
 - `AC-CONTEXT-003-03`: corpos e eventos JSONL são lidos somente após selecionar IDs específicos.
-- `AC-CONTEXT-003-04`: operações comuns nunca varrem `.agents/records` ou `.agents/data`; rebuild completo exige comando e confirmação explícitos.
-- `AC-CONTEXT-003-05`: `.agents/projections/runtime` é local, ignorado pelo Git, incremental e reconstruível a partir dos records canônicos.
+- `AC-CONTEXT-003-04`: operações comuns consultam somente manifests lifecycle e `InvocationSummary` canônicos, com paginação cursor-estável; varredura integral de `.agents/records` ou `.agents/data` exige comando e confirmação explícitos.
+- `AC-CONTEXT-003-05`: o dashboard não depende de cache ou projeção local; migrações preservam somente os manifests canônicos Git-native em `.agents/records/lifecycle` e backfill verificável.
 - `AC-CONTEXT-003-06`: `.agents/data` e partições diárias anteriores são fallback legado somente leitura; novas escritas usam `.agents/records/<kind>/<ano>/<mês>`.
 - `AC-CONTEXT-003-07`: `context build` descobre paths e relações antes de ler conteúdo; inventário integral exige comando explícito.
 - `AC-CONTEXT-003-08`: uma consulta com ID lifecycle explícito não incorpora outros itens de `active-work`; fallback de path aceita somente o arquivo V3 canônico existente sem varrer records.

package/templates/.agents/requirements/cost-observability.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-COST-OBSERVABILITY
 area: cost-observability
 title: Tokens, custos e cobertura
 status: active
-version: 9
+version: 10
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Cost observability
@@ -37,3 +37,4 @@ Runs devem poder ser localizadas e agregadas sem carregar seus eventos completos
 - `AC-COST-002-10`: agregações expõem cobertura por Run para uso, tokens e custo com quantidades conhecidas, desconhecidas e razão; ausência de eventos nunca implica cobertura completa quando existem Runs no escopo.
 - `AC-COST-002-11`: snapshot expõe `source_latest_at` e `lag_ms` calculados a partir das entidades projetadas, sem usar horário de consulta como horário da fonte.
 - `AC-COST-002-12`: fechamento de Run sem medição persiste um evento de uso explicitamente indisponível; `context build --run` registra o tamanho estimado do pack sem armazenar prompts, e respostas resumidas omitem árvores internas disponíveis em `--view full`.
+- `AC-COST-002-13`: cada Chamada LLM observada possui `MCALL-*` global e pertence a uma única Invocação de Agente; a mesma chave de fonte não pode atribuir tokens, custo ou tempo a duas invocações. A cobertura é `complete`, `partial` ou `unavailable`; o dashboard nunca apresenta uma contagem parcial como total exato.

package/templates/.agents/requirements/data-export.md

@@ -0,0 +1,57 @@
+---
+schema_version: 2
+id: REQUIREMENTS-DATA-EXPORT
+area: data-export
+title: Exportação contextual de dados para Excel
+status: proposed
+version: 2
+source_change: null
+source_release: "1.0.7"
+---
+
+# Exportação contextual de dados
+
+## REQ-EXPORT-001 — Snapshot completo e fiel
+
+O dashboard deve exportar um snapshot determinístico da visão ativa sem ampliar o acesso do usuário nem limitar o resultado ao conteúdo renderizado.
+
+- `AC-EXPORT-001-01`: Monitor de Custos, tabelas de Operação e Kanban expõem a ação **Exportar para Excel** somente nas visões elegíveis definidas pelo inventário testado.
+- `AC-EXPORT-001-02`: o snapshot captura visão, aba, filtros, busca, agrupamento, escopo, colunas e ordenação ativos no clique; mudanças posteriores da tela não alteram a exportação iniciada.
+- `AC-EXPORT-001-03`: tabelas paginadas ou virtualizadas exportam exatamente todos os registros elegíveis do snapshot, sem omissões nem duplicações, comprovados por comparação entre IDs esperados e exportados.
+- `AC-EXPORT-001-04`: no Kanban, cada cartão elegível produz exatamente uma linha com coluna/status e ordenação estável.
+- `AC-EXPORT-001-05`: a exportação preserva permissões, moeda e a distinção entre zero conhecido e valor indisponível da visão de origem.
+- `AC-EXPORT-001-06`: após a confirmação do destino, o runtime local materializa um snapshot imutável e versionado em `manifest.json` e chunks NDJSON sob `.local/data-export/snapshots/<snapshot-id>/`; o manifesto registra versão, filtros, ordenação, colunas, contagem, hashes e estado terminal, e os arquivos temporários são removidos segundo política de limpeza testada.
+
+## REQ-EXPORT-002 — Workbook Excel íntegro e particionado
+
+O resultado deve ser um ou mais arquivos XLSX formatados, íntegros e limitados a 1.000.000 de registros de dados por arquivo.
+
+- `AC-EXPORT-002-01`: cada arquivo abre sem reparo em um leitor XLSX automatizado e no Microsoft Excel do ambiente de aceite.
+- `AC-EXPORT-002-02`: cabeçalhos formatados possuem autofiltro e congelamento; números, custos, percentuais, datas, horários, durações, identificadores, zero e indisponibilidade preservam tipos e semântica verificáveis.
+- `AC-EXPORT-002-03`: nenhum arquivo contém mais de 1.000.000 de registros de dados, excluído o cabeçalho; 1.000.001 registros geram exatamente duas partes.
+- `AC-EXPORT-002-04`: partes usam estrutura idêntica, nomes sequenciais e, quando concatenadas na ordem, correspondem exatamente ao snapshot.
+- `AC-EXPORT-002-05`: cancelamento ou falha não apresenta arquivo parcial como exportação concluída.
+- `AC-EXPORT-002-06`: cada arquivo XLSX contém exatamente uma worksheet referente somente à aba ou visão capturada; uma solicitação nunca mistura duas abas da interface no mesmo arquivo.
+- `AC-EXPORT-002-07`: a contagem total do snapshot determina `ceil(total / 1.000.000)` arquivos antes da nomeação das partes; cada parte contém no máximo 1.000.000 de registros de dados, sem contar o cabeçalho.
+
+## REQ-EXPORT-003 — Destino, execução em segundo plano e progresso
+
+O usuário deve escolher o destino antes do processamento e acompanhar uma exportação não bloqueante até um estado terminal.
+
+- `AC-EXPORT-003-01`: o seletor de destino é o primeiro efeito visível do clique e nenhum processamento pesado começa antes da confirmação.
+- `AC-EXPORT-003-02`: cancelar o seletor encerra a solicitação sem iniciar geração e sem apresentar sucesso.
+- `AC-EXPORT-003-03`: após a confirmação, navegação, filtros, troca de abas e abertura de detalhes permanecem utilizáveis durante a geração.
+- `AC-EXPORT-003-04`: um aviso persistente no canto inferior direito informa que a página deve permanecer aberta e mostra etapa, barra e percentual global monotônico até `100%`.
+- `AC-EXPORT-003-05`: conclusão informa registros, arquivos e destino; falha informa causa acionável; incompatibilidade de gravação no destino é explícita e não usa download silencioso em outro local.
+- `AC-EXPORT-003-06`: existe no máximo uma exportação ativa por sessão do dashboard; uma segunda tentativa não inicia trabalho concorrente e apresenta a exportação em andamento.
+
+## REQ-EXPORT-004 — Assurance transversal
+
+A entrega deve provar fidelidade, responsividade, limite de volume e compatibilidade no candidato integrado.
+
+- `AC-EXPORT-004-01`: E2E servido cobre Monitor de Custos, tabela de Operação e Kanban com filtros, paginação e mudança de tela após o snapshot.
+- `AC-EXPORT-004-02`: testes determinísticos cobrem o cálculo das fronteiras 0, 1, 1.000.000 e 1.000.001; a ausência de perda, duplicação ou arquivo acima do limite é provada com uma fronteira reduzida equivalente, sem materializar 1.000.001 registros no teste.
+- `AC-EXPORT-004-03`: uma validação de responsividade comprova interação disponível e progresso monotônico enquanto lotes são processados.
+- `AC-EXPORT-004-04`: integração, spec review e quality review independentes produzem Evidence própria para cada SPEC, e o PRD recebe Evidence cross-SPEC para cada outcome.
+- `AC-EXPORT-004-05`: a geração usa escrita XLSX incremental no runtime local, backpressure e memória limitada ao lote corrente; o navegador não materializa o workbook completo e permanece responsivo enquanto grava o `ReadableStream` no destino escolhido.
+- `AC-EXPORT-004-06`: benchmark reproduzível em volume representativo mede snapshot, registros por segundo, tempo total, pico de memória e tamanho gerado; as fronteiras de 1.000.000 e 1.000.001 são validadas deterministicamente, sem exigir um benchmark que materialize esses volumes.

package/templates/.agents/requirements/design-system.md

@@ -6,7 +6,7 @@ title: Contrato visual e catálogo executável
 status: active
 version: 3
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Design system
@@ -37,7 +37,7 @@ O contrato deve ser demonstrado em componentes reais e navegável sem depender d
 
 Instalações novas do ZAIP-AIOS devem receber o contrato e o catálogo visual completos.
 
-- `AC-DESIGN-003-01`: `.zaip-aios/design` contém fonte e builds estáticos alinhados com
+- `AC-DESIGN-003-01`: `.agents/design` contém fonte e builds estáticos alinhados com
   `.agents/design`, cobertos por manifest e checksums.
 - `AC-DESIGN-003-02`: o template público aceita `design` como raiz V2, audita arquivos obrigatórios
   e instala `.agents/design` com integridade validada.

package/templates/.agents/requirements/execution-engine.md

@@ -6,7 +6,7 @@ title: Preparação, materialização e DAG
 status: active
 version: 10
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Execution engine
@@ -37,6 +37,8 @@ Tasks prontas podem rodar em paralelo somente quando dependências e locks decla
 - `AC-EXEC-003-01`: a DAG é global por Execution e pode atravessar fronteiras de SPEC.
 - `AC-EXEC-003-02`: conflitos de arquivo, módulo, migration, ambiente e recurso impedem concorrência.
 - `AC-EXEC-003-03`: integração e gates finais são dependências explícitas.
+- `AC-EXEC-003-04`: uma SPEC selecionada por um PRD só pode executar como Execution-filho isolada quando sua capacidade for independente, seu contrato estiver estável, não houver dependência cross-SPEC e seus write scopes não conflitarem; a Execution do PRD coordena esses filhos.
+- `AC-EXEC-003-05`: mesmo com Executions-filhas isoladas, o scheduler preserva locks globais de escopo, orçamento e segurança da DAG; Tasks e SPECs sem elegibilidade de isolamento permanecem na DAG global da Execution coordenadora.
 
 ## REQ-EXEC-004 — Task manual em fases
 
@@ -51,10 +53,10 @@ Task-first deve separar captura, preparação e execução para que mensagem per
 
 Execuções devem limitar repetição por checkpoints suaves e verificar somente o escopo necessário ao risco, preservando logs completos fora do prompt.
 
-- `AC-EXEC-005-01`: PreparedPlan pode declarar budget de ciclos, input, refresh de contexto e modo de verificação sem cancelar automaticamente trabalho válido.
-- `AC-EXEC-005-02`: Task-first gera para `lite` zero retries operacionais, zero ciclos de reparo, budget suave de 4 ciclos e 250.000 tokens de input; `standard` preserva 24 ciclos e 4.000.000 tokens; `critical` preserva checkpoint em 40 ciclos e 8.000.000 tokens.
-- `AC-EXEC-005-03`: `zaip verify --changed --risk` retorna síntese curta e grava output bruto somente em `.agents/projections/runtime/verify`.
-- `AC-EXEC-005-04`: risco `lite` executa exatamente uma validação scoped e registra exatamente uma Evidence cobrindo todos os ACs aplicáveis, sem exigir a bateria de lint, typecheck, teste, build, preview e screenshot; `standard` executa duas validações/evidências ou três no perfil elevado; `critical` executa o gate completo e os controles de garantia crítica.
+- `AC-EXEC-005-01`: PreparedPlan pode declarar budget de ciclos, refresh de contexto e modo de verificação sem cancelar automaticamente trabalho válido.
+- `AC-EXEC-005-02`: Task-first gera para `lite` zero retries operacionais, zero ciclos de reparo e budget suave de 4 ciclos; `standard` preserva 24 ciclos; `critical` preserva checkpoint em 40 ciclos.
+- `AC-EXEC-005-03`: `zaip verify --changed --risk` retorna síntese curta e grava output bruto somente em `.local/verify`.
+- `AC-EXEC-005-04`: risco `lite` executa ao menos uma validação scoped e uma Evidence cobrindo todos os ACs aplicáveis, sem teto de artefatos; `standard` executa ao menos duas validações ou três no perfil elevado, inclui teste executado e uma Evidence consolidada; `critical` aplica quality review independente e somente os controles críticos ativados pelos sinais persistidos. Nenhum perfil exige bateria irrelevante.
 - `AC-EXEC-005-05`: a skill de execução exige refresh seletivo e checkpoint compacto ao atingir os budgets suaves.
 - `AC-EXEC-005-06`: quando um plano visível é útil, cada passo começa com `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, usa somente fases aplicáveis, contém no máximo 5 passos e combina ações triviais; tarefas simples podem omitir o plano.
-- `AC-EXEC-005-07`: checkpoints medem input não cacheado reportado pelo provider e usam tokens observáveis de contexto como fallback, preservando a origem da medição sem inventar valores ausentes.
+- `AC-EXEC-005-07`: checkpoints são acionados somente por ciclos; telemetria de input não cacheado do provider e contexto observável permanece registrada com sua origem, sem inventar valores ausentes.

package/templates/.agents/requirements/kanban-dashboard.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-KANBAN-DASHBOARD
 area: kanban-dashboard
 title: Projeções operacionais e analíticas
 status: active
-version: 10
+version: 12
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Kanban and dashboard
@@ -15,7 +15,7 @@ source_release: "1.0.6"
 
 Kanban, dashboard e Cost Monitor devem projetar o estado Git-native e distinguir planejamento de execução.
 
-- `AC-DASH-001-01`: `Pronto para Executar` contém PRD/SPEC explicitamente promovido para `ready` e, excepcionalmente, Task avulsa preparada mas não executada (`planned`, `attempt_count: 0`, `started_at: null` e sem Execution iniciada). Task `draft` nunca aparece nessa coluna; Task iniciada ou tentada permanece em Execução, Verificação ou estado terminal e nunca retorna a `Pronto para Executar`.
+- `AC-DASH-001-01`: `Pronto para Executar` contém PRD/SPEC explicitamente promovido para `ready` e toda Task preparada mas não executada (`planned`, `attempt_count: 0` ou ausente, `started_at: null`, `execution_started: false` e não ativa), inclusive quando vinculada a uma SPEC. O lifecycle canônico `draft`, `ready` e terminal de PRD/SPEC prevalece sobre `work_status` derivado de conversas; Task `draft` nunca aparece nessa coluna; Task iniciada ou tentada permanece em Execução, Verificação ou estado terminal e nunca retorna a `Pronto para Executar`.
 - `AC-DASH-001-02`: PRD agrega SPECs, Tasks, Executions e Runs descendentes.
 - `AC-DASH-001-03`: SPEC agrega Tasks, Executions e Runs descendentes.
 - `AC-DASH-001-04`: Task-first permanece analisável sem ancestrais sintéticos.

package/templates/.agents/requirements/model-orchestration.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-MODEL-ORCHESTRATION
 area: model-orchestration
 title: Seleção automática e observável de modelo e effort
 status: active
-version: 5
+version: 7
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Orquestração de modelos
@@ -22,19 +22,19 @@ O projeto deve poder habilitar seleção automática de modelo, effort e velocid
 
 ## REQ-MODEL-002 — Seleção governada por Agent Run
 
-Cada Run ou Sub-Run deve resolver uma configuração única a partir do agente do catálogo, dos metadados estruturados da Task e da fase, sem depender de instrução em linguagem natural.
+Cada Invocação de Agente deve resolver uma configuração única a partir do agente do catálogo, dos metadados estruturados da Task e da fase, sem depender de instrução em linguagem natural.
 
-- `AC-MODEL-002-01`: o resolvedor aplica a precedência `override explícito da Execution -> override explícito da Task -> política automática -> defaults do projeto`, retornando modelo, effort, velocidade, origem, versão da política e ao menos um motivo enumerado.
-- `AC-MODEL-002-02`: a política considera fase, papel do agente, complexidade, risco, transversalidade, ambiguidade, rework e restrições de capacidade; risco governa assurance e não força sozinho modelo ou effort superior.
+- `AC-MODEL-002-01`: o resolvedor aplica a precedência `runtime_defaults explícito da Execution -> runtime explícito da Task -> política automática -> defaults do projeto`, retornando modelo, effort, velocidade, origem, versão da política e ao menos um motivo enumerado.
+- `AC-MODEL-002-02`: Tasks novas de PRD/SPEC persistem `model_profile` calculado de `model_signals` reais com fase-base, complexidade, transversalidade, ambiguidade, rework, custo, boundedness, volume, gatilhos `xhigh` e sinais de risco. A classificação `task-risk-v1` deriva `lite|standard|critical` e motivos enumerados; declaração conflitante é rejeitada, enquanto PreparedPlans históricos sem perfil continuam legíveis. A política considera o perfil persistido, a fase e o agente reais da chamada e restrições de capacidade; risco governa assurance e não força sozinho modelo ou effort superior.
 - `AC-MODEL-002-03`: a política inicial usa Luna para trabalho simples, delimitado ou de alto volume, Terra como baseline de implementação e teste e Sol para planejamento, revisão ou reparo ambíguo/transversal; `xhigh` só é elegível para planejamento, replanejamento, auditoria ou rework estrutural delimitado quando as quatro condições e ao menos dois gatilhos observáveis do guia forem satisfeitos.
 - `AC-MODEL-002-04`: `ultra`, `max`, effort desconhecido e modelo fora da allowlist são rejeitados antes da chamada com erro tipado, sem fallback silencioso; `xhigh` é aceito quando vier de override explícito válido ou da política elegível.
-- `AC-MODEL-002-05`: a Run raiz usa a identidade visível `zaip-agent-orchestrator`; cada Execution delega por capacidade a ao menos um executor do catálogo, conversas podem usar `zaip-agent-analyst`, e o último Sub-Run usa `zaip-agent-finalizer`.
+- `AC-MODEL-002-05`: a Invocação do Orquestrador usa a identidade visível `zaip-agent-orchestrator`; cada Execução ZAIP delega por capacidade a ao menos um executor do catálogo, conversas podem usar `zaip-agent-analyst`, e a última Invocação Delegada usa `zaip-agent-finalizer`.
 
 ## REQ-MODEL-003 — Configuração imutável por Agent Run
 
 A configuração selecionada deve ser aplicada quando o Agent Run começa e permanecer imutável até seu término.
 
-- `AC-MODEL-003-01`: o cabeçalho do Agent Run registra agente, papel, modelo e reasoning effort planejados; quando o host não expõe um campo, ele permanece `null` ou `unknown`, nunca inferido como observação.
+- `AC-MODEL-003-01`: o cabeçalho do Agent Run registra agente, papel, modelo e reasoning effort resolvidos para a invocação, e `model.selection.recorded` persiste a mesma decisão antes do dispatch; defaults do catálogo não podem substituir a seleção efetivamente invocada. Quando o host não expõe um campo efetivo, ele permanece `null` ou `unknown`, nunca inferido como observação.
 - `AC-MODEL-003-02`: toda Call interna herda exatamente o modelo, effort e velocidade `standard` do Agent Run; o ledger rejeita uma configuração solicitada divergente dentro da mesma Run.
 - `AC-MODEL-003-03`: mudança deliberada de modelo, effort, agente ou fase material exige encerrar a Run corrente e abrir outra Run relacionada; retry técnico e retomada por checkpoint preservam a configuração original.
 - `AC-MODEL-003-04`: fallback ou reroteamento feito pelo host/provider não altera a configuração planejada; modelo/effort efetivos e divergência requested/effective são observações internas da Run quando disponíveis.
@@ -42,12 +42,12 @@ A configuração selecionada deve ser aplicada quando o Agent Run começa e perm
 
 ## REQ-MODEL-004 — Telemetria agregada por Agent Run
 
-O Agent Run é a unidade visível e auditável. Calls permanecem eventos internos usados para consolidar consumo, retries e configuração efetiva sem criar um lifecycle ou uma visão paralela.
+A Invocação de Agente é a unidade visível e auditável. Chamadas LLM permanecem eventos internos usados para consolidar consumo, retries e configuração efetiva sem criar um lifecycle ou uma visão paralela.
 
 - `AC-MODEL-004-01`: quando o host expõe Calls, cada `invocation_id` possui no máximo uma seleção e um terminal idempotentes dentro do Run; todos reutilizam a decisão imutável do Agent Run e não armazenam prompt, segredo ou reasoning privado.
-- `AC-MODEL-004-02`: contagem de Calls, terminais, falhas, cancelamentos, tokens, custo, latência e configuração efetiva são agregados no Agent Run; ausência de captura permanece `null`, nunca zero ou inferida.
-- `AC-MODEL-004-03`: projeções, CLI e Cost Monitor mostram separadamente Run e Sub-Run por `parent_run_id`, propósito, identidade canônica `zaip-agent-*`, modelo/effort planejados, configuração efetiva observada, Calls conhecidas, tokens e custo por chamada de agente.
-- `AC-MODEL-004-04`: o dashboard não cria `CallProjection` nem uma aba de Calls; filtros e agregações existentes de Run, Task, SPEC, PRD, agente e modelo continuam sem dupla contagem.
+- `AC-MODEL-004-02`: contagem de Chamadas LLM, terminais, falhas, cancelamentos, tokens, custo, latência e configuração efetiva são agregados na Invocação de Agente; ausência de captura permanece `null`, nunca zero ou inferida.
+- `AC-MODEL-004-03`: projeções, CLI e Cost Monitor mostram separadamente a Invocação do Orquestrador e as Invocações Delegadas por identidade pai, propósito, `zaip-agent-*`, modelo/effort planejados, configuração efetiva observada, Chamadas LLM conhecidas, tokens e custo.
+- `AC-MODEL-004-04`: o dashboard não cria `CallProjection` nem uma aba de Chamadas LLM; filtros e agregações existentes de Invocação de Agente, Task, SPEC, PRD, agente e modelo continuam sem dupla contagem.
 
 ## REQ-MODEL-005 — Rollout medido e documentação coerente
 

package/templates/.agents/requirements/public-distribution.md

@@ -6,7 +6,7 @@ title: Distribuição pública e ativação
 status: proposed
 version: 2
 source_change: null
-source_release: "1.0.6"
+source_release: "1.0.7"
 ---
 
 # Distribuição pública e ativação
@@ -15,9 +15,9 @@ source_release: "1.0.6"
 
 O pacote público deve entregar, verificar e reparar o mesmo runtime de lifecycle referenciado pelo guidance instalado, sem depender do checkout mantenedor nem criar autoridade implícita.
 
-- `AC-DIST-001-01`: o `.tgz` exato de `@zaip-ai/cli` e `create-zaip-aios` instala `.zaip-aios/bin/zaip.mjs` e seus metadados de supply chain; no workspace vazio, `doctor`, `status`, `conversation start`, `disable` e `enable` terminam com sucesso.
+- `AC-DIST-001-01`: o `.tgz` exato de `@zaip-ai/cli` e `create-zaip-aios` instala `.agents/runtime/bin/zaip.mjs` e seus metadados de supply chain; no workspace vazio, `doctor`, `status`, `conversation start`, `disable` e `enable` terminam com sucesso.
 - `AC-DIST-001-02`: `zaip.enabled` é a única chave gravada; a matriz canônica/legada `true|false|ausente` preserva compatibilidade, normaliza a próxima escrita e rejeita valores contraditórios antes de mutar o workspace.
-- `AC-DIST-001-03`: `template:sync` e `template:audit` cobrem `.agents` e `.zaip-aios`, recalculam o digest agregado, rejeitam path traversal, symlink, duplicata, descendente de arquivo allowlisted e checksum divergente.
+- `AC-DIST-001-03`: `template:sync` e `template:audit` cobrem `.agents`, incluindo `.agents/runtime`, recalculam o digest agregado, rejeitam path traversal, symlink, duplicata, descendente de arquivo allowlisted e checksum divergente.
 - `AC-DIST-001-04`: geração de runtime e manifest ocorre como uma única substituição recuperável; falhas injetadas antes e depois da troca preservam byte a byte o runtime e o manifest anteriores, e reinstalação autorizada restaura arquivo ausente.
 
 ## REQ-DIST-002 — Qualificação e paridade de release
@@ -25,7 +25,7 @@ O pacote público deve entregar, verificar e reparar o mesmo runtime de lifecycl
 A distribuição pública só pode ser candidata quando fonte canônica, template, artefato, documentação e smoke do pacote exato descrevem o mesmo contrato observável.
 
 - `AC-DIST-002-01`: o gate de release executa sync reproduzível, audit, typecheck, testes, pack, doctor, smoke e rollback sobre o candidato exato, sem substituir falha por evidência de outro checkout.
-- `AC-DIST-002-02`: o manifest registra versão, hashes e conteúdo efetivo de `.agents` e `.zaip-aios`; qualquer divergência entre fonte, template e pacote bloqueia a candidatura.
+- `AC-DIST-002-02`: o manifest registra versão, hashes e conteúdo efetivo de `.agents`, incluindo o runtime; qualquer divergência entre fonte, template e pacote bloqueia a candidatura.
 - `AC-DIST-002-03`: README, guias de instalação, versão pública e comandos documentados permanecem alinhados ao pacote qualificado e não prometem capability ausente.
 
 ## REQ-DIST-003 — Configuração global portátil do Codex