@zaip-ai/cli 2.2.0 → 2.6.0

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

@@ -2,9 +2,11 @@
 id: RULE-FRONTEND-LITE
 load: auto
 priority: high
-max_context_tokens: 450
+max_context_tokens: 425
 requires:
   - RULE-WORKFLOW
+triggers: [frontend, interface, ui, css, componente, component, visual]
+phases: [definition, planning, execution, verification]
 ---
 
 # Perfil frontend lite canônico

package/templates/.agents/rules/local-sqlite-storage.md

@@ -2,9 +2,9 @@
 id: RULE-LOCAL-SQLITE-STORAGE
 load: file_match
 priority: high
-max_context_tokens: 450
+max_context_tokens: 400
 requires: [RULE-ARCHITECTURE]
-globs: [".local/**", "**/*sqlite*.*", "**/*sqlite*/**", ".agents/dashboard/**"]
+globs: [".local/sqlite/**", "**/*sqlite*.*", "**/*sqlite*/**", ".agents/dashboard/**/sqlite/**", ".agents/dashboard/**/sqlite-*.ts"]
 ---
 
 # Armazenamento SQLite local

package/templates/.agents/rules/meta-mcp.md

@@ -2,10 +2,12 @@
 id: RULE-META-MCP
 load: auto
 priority: high
-max_context_tokens: 650
+max_context_tokens: 675
 requires:
   - RULE-CORE
   - RULE-SECURITY
+triggers: ["meta ads", "meta mcp", facebook, "graph api", "meta devtools"]
+domains: [meta, facebook, graph]
 ---
 
 # Meta MCP

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

@@ -2,7 +2,7 @@
 id: RULE-MODEL-ORCHESTRATION
 load: manual
 priority: high
-max_context_tokens: 1100
+max_context_tokens: 900
 requires:
   - RULE-CORE
 ---

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

@@ -2,22 +2,24 @@
 id: RULE-RUN-LIFECYCLE-CLOSURE
 load: auto
 priority: critical
-max_context_tokens: 840
+max_context_tokens: 950
 requires:
   - RULE-CORE
   - RULE-WORKFLOW
+triggers: [fechamento, closure, finalizador, finalizer, terminalização, terminal, rollback]
+phases: [execution, verification, evidence]
 ---
 
 # Fechamento canônico de Runs e trabalho unificado
 
 - 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.
+- Cada Run raiz que governa uma Task controla uma tentativa; antes de terminar, essa 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/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.
+- Em delivery e interaction delegada, 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.
+- 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. A exigência de finalizador aplica-se somente a `delivery` e `interaction` com descendente delegado; interaction read-only sem descendentes conclui após a resposta. Nesses fluxos, toda terminalização é 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.
 - 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.

package/templates/.agents/rules/security.md

@@ -2,9 +2,11 @@
 id: RULE-SECURITY
 load: auto
 priority: critical
-max_context_tokens: 1100
+max_context_tokens: 325
 requires:
   - RULE-CORE
+triggers: [segurança, security, "security review", vulnerabilidade, credential, credencial]
+domains: [segurança, security, vulnerabilidade, credential, credencial]
 ---
 
 # Segurança e infraestrutura canônicas

package/templates/.agents/rules/specialist-routing.md

@@ -2,9 +2,11 @@
 id: RULE-SPECIALIST-ROUTING
 load: auto
 priority: high
-max_context_tokens: 650
+max_context_tokens: 550
 requires:
   - RULE-CORE
+triggers: [delegação, delegation, especialista, specialist, executor]
+phases: [planning, execution]
 ---
 
 # Roteamento por decisão e entrega primária

package/templates/.agents/rules/text-writing-utf8.md

@@ -2,7 +2,7 @@
 id: RULE-TEXT-WRITING-UTF8
 load: always
 priority: high
-max_context_tokens: 120
+max_context_tokens: 110
 requires:
   - RULE-CORE
 ---

package/templates/.agents/rules/workflow.md

@@ -2,9 +2,11 @@
 id: RULE-WORKFLOW
 load: auto
 priority: critical
-max_context_tokens: 2000
+max_context_tokens: 2250
 requires:
   - RULE-CORE
+triggers: [workflow, fluxo, lifecycle, ciclo, task, tarefa, spec, prd, change, execução, execution]
+phases: [planning, execution, verification, evidence]
 ---
 
 # Workflow e rastreabilidade canônicos
@@ -12,15 +14,15 @@ requires:
 - Pensar/explorar PRD/SPEC é Conversation sem artefato. Criar/refinar explicitamente persiste PRD/SPEC `draft`, PreparedPlan, Run e `creation_run_id` em Execution `interaction`, sem Task, Change ou delivery; agregue duração/tokens/custo só observados/reconciliados. `ready` explícito materializa DAG, Execution, Changes e Tasks `planned` sem iniciá-las; `execute` materializa e inicia. A interaction não rebaixa a visibilidade `draft`.
 - Fluxos: `PRD -> SPECs independentes -> PreparedPlan -> ready Tasks`, `SPEC standalone -> PreparedPlan -> ready`, ou Task-first. Use uma SPEC por padrão; outra requer paralelismo verificável, contrato estável e write scopes sem conflito. Dependências pertencem à SPEC; integração cross-SPEC é gate parental do PRD.
 - Colunas: Definição só PRD `draft`; Planejamento só SPEC `draft`; Pronto para Executar recebe macro `ready` e Task `planned`, não ativa/nunca iniciada ou tentada. Task `draft` não entra; iniciada/tentada fica em Execução, Verificação ou terminal e não retorna.
-- Todo turno tem Execution/Run raiz, mas só trabalho executável tem Task. Pergunta, explicação, status, análise pontual ou baixa confiança usa `interaction`, `phase: conversation`, `entrypoint: conversation`, sem Task/Change artificial. Mencionar ou discutir PRD/SPEC não autoriza criação: somente pedido humano explícito de criar, com autorização estruturada de definição, materializa macro. Sem esse pedido, leitura permanece Conversation; mutação persistente ou resultado independente cria Task-first sem ancestrais PRD/SPEC sintéticos. Continuação, resposta, aprovação, refinamento e rework só reutilizam foco na mesma `client_thread_id`; nova Task explícita prevalece. Fora da exceção draft, mutação persistente ou resultado independente cria Task antes de `prepare -> execute`; deploy/push/publicação puros são Git-only.
+- Todo turno tem Execution/Run raiz, mas só trabalho executável tem Task. Pergunta, explicação, status, análise pontual ou baixa confiança usa `interaction`, `phase: conversation`, `entrypoint: conversation`, sem Task/Change artificial. Mencionar PRD/SPEC não autoriza criação; leitura permanece Conversation. Fora da criação explícita de draft, mutação persistente ou resultado independente cria Task-first; deploy/push/publicação puros são Git-only.
 - PRD pode ser draft sem SPEC, mas `prepare|execute|deliver` exige SPEC e veda Change direta fora dela; só SPECs selecionadas pelo PreparedPlan contam. `task create` só persiste draft; Run de captura é separado. `prepare` pré-aloca IDs/valida DAG sem produto, Change, Execution ou Run de execução; em PRD/SPEC não cria Task nem promove draft. Task auto-prepare só sem `depends_on`; dependência exige `zaip plan build` completo.
 - Só pedido humano explícito move PRD/SPEC a `ready`; executar autoriza `prepare` necessário e `execute`. Criação, revisão, refinamento, aprovação de conteúdo ou planejamento genérico não promovem. Até cinco perguntas críticas no primeiro turno e três de esclarecimento; depois decisão técnica IA delegável. Não presuma credencial, autoridade externa/destrutiva, obrigação legal ou segurança não delegável.
 - Resolva verbo por alvo/status: `finalize|conclua|deixe pronto` em `draft|ready` significa `ready`; conclusão de implementação em `active` continua Tasks/gates; `execute` usa o menor grão nomeado. `implemente` sem alvo conversa; em draft finaliza plano, ready executa, active|blocked|failed continua/retoma/rework. `desenvolva|melhore|aprimore` planeja/refina/rework e requer nova promoção. PRD cancelado é imutável; sucessor draft usa `tags:[rework]` e `rework_of_prd_id`.
 - `execute` é explícito/idempotente e materializa DAG antes da primeira mutação; `execution` inicia na tentativa mesmo sem diff, comprovado separadamente por `changed_files`/`result`. Pedido avulso de ação materializa/inicia Task, Change, Execution e Run raiz antes da mutação; só fica pronto se o usuário autorizou apenas planejamento/preparo. Refinamento draft é Git-native, incrementa `revision`/`updated_at`; após prepare gere revisão/rework, sem Task extra salvo pedido/resultado independente.
 - Toda mudança de código tem Change antes da implementação; `change.md` registra plano, decisão, Evidence, eval, teste e resultado. Requirements são verdade funcional/técnica; Change aplica delta só após AC/Evidence. Task é trabalho executável, Execution tem snapshot DAG, invocação orquestradora é inicial, delegada é subagente e chamada LLM é evento observável.
-- `RUN-*` é chave física de invocação: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva. `MCALL-*` é global e pertence a uma invocação; `owner|contributor` é legado normalizado. Interaction read-only sem descendentes conclui após a resposta, sem executor/finalizador. Interaction com descendente delegado e toda delivery usam raiz `zaip-agent-orchestrator`, executor por capacidade e último delegado `zaip-agent-finalizer`; reviewer/auditor/integrator podem precedê-lo, e auto-settlement nunca encerra interaction com filho ativo. Run filha não fecha macro; SPEC/PRD ficam active até Tasks/gates parentais. Status técnico é separado do resultado Task; `blocked` usa `task resume`, `failed` `task rework`, `completed|cancelled` são imutáveis.
+- `RUN-*` é chave física de invocação: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva. `MCALL-*` é global e pertence a uma invocação; `owner|contributor` é legado normalizado. As condições de executor, finalizador, terminalização e retomada pertencem a `RULE-RUN-LIFECYCLE-CLOSURE`.
 - Reconciliação global só após confirmação humana no popup, nunca abrir dashboard/turno/intervalo; usa `task_complete` exato ou falha órfã após dez minutos, sem inferir cancelamento/sucesso. Risco é `lite|standard|critical`; anexos só por risco/Evidence. Assurance V1: standalone lite uma validação/Evidence e teste só lógica/regressão; standard 2–3 validações, teste e Evidence consolidada; critical 3+ e quality review independente. Mutação, rollback, commit final e Evidence/AC dependem de sinais persistidos; sem sinal preserve gate conservador. SPEC/PRD adicionam matriz parental, 3 validações/Evidences, integração e revisão independente.
-- `execution.runtime` ausente/manual não invoca provider; autonomous é opt-in e integra somente commits de worktree limpa, write scopes e gates tipados. Toda Task concluída com mutação usa provider efetivo `CODEX|CLAUDE`, sem `AUTO`: a linhagem evidenciada usa `[P:XXXX] [S:XXXX] [T:XXXX]`, Task sem PRD/SPEC usa `[Task-first:XXXX]` e commit sem Task usa só `[CODEX] <título funcional>` sem `ZAIP-Task`; o assunto é ≤96 e só o título reduz por palavra, e IDs completos disponíveis ficam em trailers `ZAIP-*`.
-- Pedido explícito no turno de `deploy|push|publicar|publicação GitHub` autoriza o `$zaip-skill-github-deploy` a reconciliar com segurança somente a branch e o worktree selecionados e a formar commits funcionais apenas do diff pretendido/evidenciado, sempre com pathspecs explícitos. Esta autorização substitui a limitação anterior a uma frase específica; use `rebase` por padrão, ou `merge` quando o usuário o escolher, mantendo referência recuperável e stash nomeado. Quando PRD/SPEC/Task não existirem, o commit usa `[CODEX] <título funcional>` e não contém IDs ou trailers `ZAIP-*` inventados. Nunca autoriza staging amplo, `git add -A`, force, segredos, squash, feature alheia ou worktree não selecionado.
+- `execution.runtime` ausente/manual não invoca provider; autonomous é opt-in e integra commits por scopes/gates. Commit de produto exige Task real e seu título: `[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX]`, ou `[Task-first:XXXX]` sem PRD/SPEC. Assunto ≤96, título reduz por palavra, IDs completos em trailers `ZAIP-*`. Somente `.agents/records/**` e `.local/**` dispensam identidade; `.agents` inteira não. Nunca escolher a última Task global. Política: `.agents/skills/zaip-skill-task/references/commit-policy.md`.
+- Pedido explícito de `deploy|push|publicar|publicação GitHub` autoriza `$zaip-skill-github-deploy` a reconciliar branch/worktree selecionados e commitar o diff evidenciado com pathspecs explícitos. Consumidor é GitHub-only e independente. Release inicia `v1.0`, incrementa minor, muda major só por pedido e reutiliza tag só com SHA idêntico. No framework, o helper resolve `vN.N` e pacote `N.N.0`; só GitHub Actions publica npm. Release beta é prerelease sem sufixo; `main` é promoção humana. Use `rebase` por padrão ou `merge` escolhido pelo usuário, com referência recuperável e stash nomeado. Produto exige Task atribuída; publicar commits existentes continua Git-only. Nunca staging amplo, `git add -A`, force, segredos, squash, feature alheia ou outro worktree.
 - Executar uma entrega autoriza seu commit local via `task commit TASK --files PATH[,PATH] --run RUN` antes da prova final; preserve o index alheio e resolva sobreposição de autoria. Git, HEAD e identidade devem estar prontos antes de iniciar. Conversas não criam commits artificiais. `validation execute` usa o Node do host e script relativo versionado/revisado no SHA, sem código inline/loaders; a worktree comprova o candidato, não é sandbox do SO. Só essa prova separa alterações concorrentes da entrega intacta; registros manuais mantêm o gate conservador. Documento externo exige revisão identificada ou exportação versionada. Commit não autoriza push nem substitui revisão/finalizador.
 - Plano visível: `DEFINE:` contexto/resultado/critério, `PLAN:` ciclo/DAG, `EXECUTE:` mudança, `VERIFY:` valida/Evidence/encerra; não use artefato como fase nem narre comandos internos. Registre decisão humana/IA com origem junto de Change/Execution; derive ledger do Git diff e preserve alterações do usuário. Estado novo fica em `.agents/records/<kind>/<ano>/<mês>`; diário, `.agents/data` e V1 são legado só leitura até migração explícita.

package/templates/.agents/runtime/VERSION

@@ -1 +1 @@
-2.2.0
+2.6.0