@zaip-ai/cli 1.0.8 → 1.3.1

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.0.8"
+source_release: "1.3.1"
 ---
 
 # 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.

package/templates/.agents/runtime/VERSION

@@ -1 +1 @@
-1.0.8
+1.3.0