@zaip-ai/cli 1.3.0 → 1.3.2

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

@@ -6,7 +6,7 @@ title: Exportação contextual de dados para Excel
 status: proposed
 version: 2
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Exportação contextual de dados

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.3.0"
+source_release: "1.3.2"
 ---
 
 # Design system

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

@@ -4,9 +4,9 @@ id: REQUIREMENTS-EXECUTION-ENGINE
 area: execution-engine
 title: Preparação, materialização e DAG
 status: active
-version: 10
+version: 11
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Execution engine
@@ -59,4 +59,4 @@ Execuções devem limitar repetição por checkpoints suaves e verificar somente
 - `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 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.
+- `AC-EXEC-005-07`: checkpoints suaves de contexto 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. Checkpoints de segurança por esgotamento de tentativas semânticas são distintos desse contador. Observações de convergência não concedem aprovação nem cancelam trabalho por duração; tempo não observado permanece indisponível.

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

@@ -4,13 +4,21 @@ id: REQUIREMENTS-KANBAN-DASHBOARD
 area: kanban-dashboard
 title: Projeções operacionais e analíticas
 status: active
-version: 13
+version: 14
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Kanban and dashboard
 
+## REQ-TRACE-SELECTOR-OPEN — Opções do seletor de Tasks
+
+O seletor da aba Rastreabilidade deve abrir a lista completa ao clicar no campo, inclusive quando já existe uma Task selecionada, preservando busca, seleção e acessibilidade.
+
+- `AC-TRACE-SELECTOR-OPEN-01`: clicar no campo com Task selecionada abre todas as opções.
+- `AC-TRACE-SELECTOR-OPEN-02`: digitar filtra opções e selecionar continua carregando a Task.
+- `AC-TRACE-SELECTOR-OPEN-03`: o comportamento possui teste focado acessível.
+
 ## REQ-DASH-001 — Estado e visão macro
 
 Kanban, dashboard e Cost Monitor devem projetar o estado Git-native e distinguir planejamento de execução.

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

@@ -6,7 +6,7 @@ title: Seleção automática e observável de modelo e effort
 status: active
 version: 7
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Orquestração de modelos

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

@@ -6,7 +6,7 @@ title: Distribuição pública e ativação
 status: active
 version: 3
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Distribuição pública e ativação

package/templates/.agents/requirements/software-architecture.md

@@ -6,7 +6,7 @@ title: Layout modular e limites de código-fonte
 status: active
 version: 5
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Software architecture

package/templates/.agents/requirements/strategic-improvements.md

@@ -6,7 +6,7 @@ title: Melhorias estratégicas de custo, qualidade e resiliência
 status: active
 version: 1
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Melhorias estratégicas de custo, qualidade e resiliência

package/templates/.agents/requirements/work-lifecycle.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-WORK-LIFECYCLE
 area: work-lifecycle
 title: Ciclo de vida do trabalho
 status: active
-version: 23
+version: 24
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Work lifecycle
@@ -36,8 +36,8 @@ Cada alteração de código deve possuir Change criada antes da mutação, com n
 
 - `AC-WORK-002-01`: `change.md` registra plano, implementação, decisões, evidências, evals, testes e resultado.
 - `AC-WORK-002-02`: decisões distinguem origem `human` e `ai`, inclusive quando não houve decisão.
-- `AC-WORK-002-03`: cada evidência referencia o Acceptance Criterion comprovado.
-- `AC-WORK-002-04`: somente artefatos tipados, aprovados, vinculados à Task/Change/Execution/Run e ao commit esperado contam para assurance; declaração textual ou teste não executado não conta.
+- `AC-WORK-002-03`: cada evidência referencia o Acceptance Criterion comprovado. Nas novas entregas, executor/revisor definem cenário, expectativa, modalidade e ambiente autorizado antes da implementação e registram resultado observado, momento real, candidato/ambiente efetivamente examinados, locators e limitações conforme o contrato compartilhado de prova observável da skill Change. Prova visual exige captura real examinada; integração entre componentes exige correlação do cenário. Verificar por exemplos discriminantes, schema e testes CLI; a CLI registra a observação declarada, não executa o procedimento nem certifica sua veracidade automaticamente.
+- `AC-WORK-002-04`: somente artefatos tipados, aprovados, vinculados à Task/Change/Execution/Run e ao commit esperado contam para assurance; declaração textual ou teste não executado não conta. Observações V1 são sidecars referenciados por locators da Evidence V2, sem novos estados de Task. Registro e leitura de assurance rejeitam referências ausentes, inválidas, não confirmadas ou incompatíveis em identidade, AC e candidato. Estados limited/pending/failed/not_applicable não alimentam aprovação; confirmação exige identidade de candidato/ambiente e contexto pertinente. Preservar V2 sem observações, sem promover históricos, exigir observações retroativamente ou autorizar reuso entre Runs. Verificar caminhos positivos/negativos do writer e reader e compatibilidade de locators legados; seleção de todas as modalidades obrigatórias e invalidação ambiental continuam sob revisão, não são inferidas automaticamente.
 - `AC-WORK-002-05`: entregas originadas de SPEC ou PRD mantêm uma matriz parental de AC, validações de integração e Evidences próprias, sem reutilizar a mera quantidade de artefatos das Tasks como prova da entrega.
 - `AC-WORK-002-06`: cada outcome de PRD possui um `OUT-*` persistido e único, alinhado 1:1 ao texto humano; delivery consome esse campo tipado sem cast estrutural e bloqueia outcome vazio, duplicado, órfão ou sem Evidence parental vinculada ao commit final e a Run independente.
 

package/templates/.agents/requirements/zaip-strategic-95.md

@@ -6,7 +6,7 @@ title: Evidências, custo por Task e autonomia por SPEC
 status: active
 version: 1
 source_change: null
-source_release: "1.3.0"
+source_release: "1.3.2"
 ---
 
 # Evidências, custo por Task e autonomia por SPEC

package/templates/.agents/rules/dashboard-ui-consistency.md

@@ -0,0 +1,14 @@
+---
+id: RULE-DASHBOARD-UI-CONSISTENCY
+load: file_match
+priority: high
+max_context_tokens: 260
+requires: [RULE-ARCHITECTURE]
+globs: [".agents/dashboard/apps/frontend/**", ".agents/dashboard/modules/**/src/react/**", ".agents/dashboard/packages/ui/**"]
+---
+
+# Consistência UI do Dashboard
+
+- Inventarie e reutilize `@zaip-ai/dashboard-ui`; dados tabulares usam `DataTable`, salvo Decision explícita.
+- Reutilize componente compartilhado e contêiner canônico; implemente loading, empty, error e paginação quando aplicáveis.
+- Exija render determinístico e bundle servido quando distribuição/preview forem afetados. Impacto visual exige captura real examinada no estado pedido, conforme o contrato de prova observável da skill Change. Browser admite fallback finito; sem captura, AC visual pendente, nunca aprovação integral nem bloqueio do trabalho independente.

package/templates/.agents/rules/frontend-lite.md

@@ -9,10 +9,10 @@ requires:
 
 # Perfil frontend lite canônico
 
-- Classifique como `lite` somente mudança de frontend local, reversível e puramente visual, limitada a até 3 arquivos de um único componente, como trocar ícone, cor, espaçamento, texto curto ou classe CSS.
+- `lite`: frontend local, reversível e puramente visual, até 3 arquivos de um componente (ícone, cor, espaço, texto curto ou CSS).
 - Promova para `standard` se houver lógica, estado, navegação, formulário, dados, API, persistência, dependência, configuração, token global, layout responsivo, semântica de acessibilidade ou alcance entre componentes.
 - Promova para `critical` se houver autenticação, autorização, segredo, pagamento, privacidade, perda de dados, contrato público ou ação irreversível.
-- Em `lite`, dispense plano visível, exploração ampla e anexos extras. Faça somente a delegação mínima obrigatória pelo lifecycle (executor elegível e finalizador), sem subagentes adicionais. Use um único critério de aceite que descreva exatamente a alteração pedida.
-- Em `lite`, valide somente o diff dos arquivos alterados. Não execute lint, typecheck, teste, build, preview, screenshot ou E2E, salvo pedido explícito do usuário ou lógica/regressão declarada.
-- Se o usuário já confirmou visualmente o resultado, encerre após conferir o diff; não repita validações.
+- Dispense exploração ampla e anexos extras; use um AC exato, executor elegível e finalizador, sem delegação adicional.
+- Confira o diff e uma captura real examinada da versão/estado pedidos, conforme o contrato de prova observável da skill Change. Não repita screenshot válido; ausência de captura mantém o AC visual pendente após fallback finito, sem impedir trabalho independente.
+- Lint, typecheck, teste, build e E2E só quando necessários ao impacto, à versão servida ou explicitamente pedidos; não os repita por cerimônia. Confirmação humana pode compor a prova, mas não substitui o registro da captura.
 - Interrompa o perfil `lite` e reclassifique ao encontrar qualquer impacto fora dos critérios acima.

package/templates/.agents/rules/run-lifecycle-closure.md

@@ -10,15 +10,15 @@ requires:
 
 # Fechamento canônico de Runs e trabalho unificado
 
-- Toda Execution de `interaction` ou `delivery` tem uma Run raiz do `zaip-agent-orchestrator`. Interaction read-only sem descendentes conclui após a resposta sem executor/finalizador; interaction com descendente delegado e delivery aguardam a árvore inteira e exigem ao menos um executor elegível pelas capacidades do catálogo.
+- Toda Execution tem raiz `zaip-agent-orchestrator`. Interaction read-only sem descendentes conclui após a resposta sem executor/finalizador; interaction delegada e delivery aguardam a árvore inteira e exigem executor elegível pelo catálogo.
 - Cada Run raiz governa uma tentativa; antes de terminar, a Task já está em `completed`, `blocked`, `failed` ou `cancelled`. `executing` e `verifying` nunca sobrevivem ao fim da tentativa.
-- A raiz é a única invocação `orchestrator`, sem pai e em profundidade zero. Toda invocação delegada tem pai, raiz e profundidade positiva; `RUN-*` permanece somente sua chave física compatível.
-- O último filho é exatamente um Sub-Run do `zaip-agent-finalizer` com propósito `finalization` em interaction delegada ou delivery. Ele só inicia depois do executor elegível e dos demais descendentes; sua barreira impede novos Sub-Runs. Auto-settlement nunca fecha interaction com descendente ativo.
+- A raiz é a única invocação `orchestrator`, sem pai/profundidade zero. Delegadas têm pai, raiz e profundidade positiva; `RUN-*` é chave física compatível.
+- O último filho é exatamente um Sub-Run do `zaip-agent-finalizer` em `finalization`. Inicia após executor elegível e demais descendentes; sua barreira impede novos Sub-Runs. Auto-settlement não fecha interaction com descendente ativo.
 - O finalizador avalia gates e Evidence e retorna somente `completed`, `blocked`, `failed` ou `cancelled`, com motivo e referências. A CLI aplica o estado terminal canônico. Finalizador ausente, incompleto ou falho bloqueia a Task antes de a Run raiz terminar.
 - O resultado da Task é separado do status técnico da Run/Sub-Run: uma orquestração tecnicamente `completed` pode produzir Task `blocked` se gate, validação ou Evidence não passar.
 - Use `completed` somente com gates e Evidences aprovados; `blocked` para dependência externa, autoridade ou informação ausente, gate/teste pendente, falta de Evidence, limite de tempo/contexto ou outra inconclusão. Registre o motivo e a condição objetiva de retomada.
 - Use `failed` somente para erro técnico ou de integridade comprovadamente impeditivo. Nunca use `failed` por tempo, silêncio do usuário, escopo incompleto ou gate pendente; esses casos são `blocked`. `cancelled` requer pedido humano explícito e nunca é inferido. Toda terminalização, inclusive cancelamento de Task/SPEC/PRD ou Run, só é aplicada pelo orquestrador após Gui concluir o Sub-Run finalizador.
 - `blocked` retoma com `task resume`; `failed` exige `task rework` na mesma Task, incrementa a tentativa e inicia nova Run. A continuação não preserva Task em `executing` ou `verifying`; `completed` e `cancelled` são imutáveis.
-- Uma Run de SPEC/PRD não terminaliza o macro a cada turno ou Task: o pai fica `active` durante a execução, inclusive nos intervalos, e somente passa à Verificação depois de todas as Tasks terminarem, antes dos gates parentais de delivery.
+- Run de SPEC/PRD não terminaliza o macro a cada turno/Task: o pai fica `active`, inclusive nos intervalos, até todas as Tasks terminarem; depois passa à Verificação e aos gates parentais.
 - `run reconcile --open` é reparação manual: só ocorre após confirmação humana no popup Reconciliar, nunca ao abrir/atualizar o dashboard, em cada turno ou por intervalo. Fecha somente `task_complete` local exato; Run órfã sem invocação ativa por dez minutos falha tecnicamente; gates ausentes bloqueiam; conclusão e cancelamento nunca são inferidos.
 - Dashboard e projeções exibem apenas o estado canônico persistido. Nenhum consumidor revive Task terminal por heurística de invocação local nem reaplica estado como se fosse reconciliação.