@zaip-ai/cli 4.7.0 → 4.9.0

package/templates/.agents/rules/production-readiness.md

@@ -0,0 +1,24 @@
+---
+id: RULE-PRODUCTION-READINESS
+load: auto
+priority: high
+max_context_tokens: 850
+requires:
+  - RULE-CORE
+  - RULE-AUTONOMY-DECISION
+triggers: [prontidão, readiness, nota, estabilidade, qualificação, qualification, release]
+phases: [planning, execution, verification, evidence]
+---
+
+# Qualificação técnica essencial
+
+- Para avaliações novas de PRD/SPEC/DAG/release, use o aceite binário `proportional-acceptance-v1` em `@zaip-ai/specs` e o contrato de `docs/quality/production-readiness.md`: origem, aplicabilidade, resultado, prova, responsável e parada por critério obrigatório. Falta de obrigatório bloqueia; melhoria opcional pendente não bloqueia. Não recalcule snapshots antigos sem migração explícita. A nota histórica é informativa, não gate adicional.
+- Declare Windows como ambiente local obrigatório do candidato atual; Linux no GitHub é smoke remoto do pacote exato. Não crie Docker, WSL ou outro SO local para satisfazer preferência. Segurança e integridade aplicáveis permanecem gates.
+- A API técnica de notas `technical-essential-v1` continua compatível, documentada em `docs/quality/production-readiness.md`. Notas 9 e 10 avaliam o candidato no escopo declarado de uso, plataformas e runtimes. Não exigem dias de observação nem contagem mínima de ciclos reais; não são garantia de ausência de defeitos nem certificação de estabilidade prolongada.
+- Nota 9 exige todos os seis critérios: instalação/upgrade com preservação, comportamento principal, agentes/rastreabilidade, falha/retomada/idempotência, segurança/rollback/reaplicação e integridade/revisão independente. Critérios essenciais não admitem N/A. Nota 10 acrescenta concorrência, interrupção/recuperação de processo do projeto e carga representativa. N/A somente nesses extras, com justificativa técnica e revisão independente, exibido como N/A.
+- Defina escopo antes dos testes. Prova ausente, falha impeditiva, candidato/ambiente incompatível ou revisão não independente impede aprovação. Não omita plataforma anunciada nem estreite escopo para apagar falha. O avaliador checa consistência: o chamador examina a Evidence real; fixtures não comprovam prontidão do produto.
+- Teste o impacto durante implementação e qualifique a integração pertinente no candidato final. Reutilize preparo válido, repita testes afetados após correção e amplie conforme risco. Não imponha repetição sem motivo nem remova gates aplicáveis de segurança, distribuição, CI, assinatura ou lifecycle para acelerar.
+- Para reuso de grupos rapid após recibo assinado, siga `docs/quality/v49-deploy-cache-controls.md`: prova versionada e revisada por grupo; promova falha como tombstone antes de retry, sem reaproveitar PASS anterior.
+- Recuperação usa o perfil congelado e seu ledger. No padrão configurado `balanced`, mantenha até 3 replans (Sol/high, Sol/high, Astra/high) e 10 execuções totais; cada replan libera até 3 reparações. Continue automaticamente enquanto a recuperação for elegível, sem quarto replan, sem reset em retomada e sem contar testes/tool calls/relógio como tentativas. Preserve contratos `essential` e `persistent`.
+- Falta real de autoridade, acesso ou informação essencial pode bloquear antes do esgotamento; não execute três tentativas inúteis. Bloqueio terminal registra causa, provas, tentativas e condição de retomada. Nunca reduza ACs para encerrar.
+- A janela histórica permanece somente na API legada. Preserve auditorias antigas sem recalcular notas. Acompanhe incidentes e uso real separadamente; incidente impeditivo conhecido bloqueia aceite. Nota técnica, publicação e fechamento canônico são estados distintos.

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

@@ -5,8 +5,8 @@ priority: critical
 max_context_tokens: 325
 requires:
   - RULE-CORE
-triggers: [segurança, security, "security review", vulnerabilidade, credential, credencial]
-domains: [segurança, security, vulnerabilidade, credential, credencial]
+triggers: [segurança, security, "security review", vulnerabilidade, credential, credencial, login, autenticação, authentication, auth]
+domains: [segurança, security, vulnerabilidade, credential, credencial, login, autenticação, authentication, auth]
 ---
 
 # Segurança e infraestrutura canônicas

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

@@ -20,10 +20,10 @@ phases: [planning, execution, verification, evidence]
 - 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-*` identifica invocação física: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva, mesmo quando o agente filho orquestra uma Task. Task é a unidade de tentativa; PRD/SPEC coordenam dependências e aceite parental. `MCALL-*` pertence a uma invocação; fechamento e retomada seguem `RULE-RUN-LIFECYCLE-CLOSURE`.
+- `RUN-*` identifica por padrão uma invocação física: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva, mesmo quando o agente filho orquestra uma Task. A exceção versionada de `spec execute` após definição terminal+Gui e autorização explícita observada cria um segmento lógico sucessivo da mesma invocação física, com claim e predecessor exatos; nunca dois proprietários ativos, turno inventado ou child sem spawn nativo. Task é a unidade de tentativa; PRD/SPEC coordenam dependências e aceite parental. `MCALL-*` pertence à invocação física; uso sem fronteira observável não é duplicado entre segmentos. Fechamento e retomada seguem `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.
 - Novos projetos usam `execution.runtime: codex_native`: a execução fica no host Codex, com subagentes nativos observados também para Task avulsa. Ausente/manual não invoca provider; `managed` e `autonomous` são contratos explícitos de compatibilidade, não o padrão da v4. Commit exige Task real e 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 última Task global. Política: `.agents/skills/zaip-skill-task/references/commit-policy.md`.
-- Pedido explícito de deploy/push/publicação GitHub resolve modo antes de qualificação em `$zaip-skill-github-deploy`: política project-owned `.agents/config/deploy-policy.json`, schema 1, `default_mode: auto|commits|release`; auto usa Release + npm via Actions no builder verificado e commits + push no consumidor. “apenas commits/sem release” e “deploy com release/próxima versão/novo release” são overrides do pedido, não preferência permanente; discussão/negação não autoriza publicação e prepare não publica. Escopo padrão `current-work`; só “deploy de tudo” amplia para `all-worktree`. Preserve trabalho/index concorrentes e causalidade de todos os commits publicados. Não peça confirmação rotineira nem aviso extra de pipeline existente; mantenha bloqueios reais de integridade/auth/destruição/expansão. Aplicação segue frontend/backend literal, inclusive main, sem criar beta; só banco mantém beta e promoção humana. Origem local/detached é separada do alvo remoto; use ref recuperável, stash nomeado, rebase padrão ou merge autorizado e refspec SHA explícito. Commits usam `guarded-commits.mjs` e checks por impacto; release usa qualificação pertinente/protected helper, com gates densos do builder só em release salvo impacto direto installer/segurança. Sem suíte completa automática, teto de testes ou regra de relógio da Task; balanced mantém 10 execuções/3 replanos. Consumidor release é GitHub-only, sem npm/chave/política protegida do builder. Release inicia v1.0, minor numérico, major explícito; retry conserva SHA/identidade, SHA já publicado é no-op. Builder vN.N = N.N.0. Notas detalhadas só na Release, fonte/Evidence no range Git completo; chat breve. Produto exige Task atribuída; commits existentes seguem Git-only. Nunca staging amplo, force, segredos, squash, feature alheia ou outro worktree.
+- Pedido explícito de deploy/push/publicação GitHub segue `$zaip-skill-github-deploy` e `.agents/config/deploy-policy.json`. Resolva modo e escopo pelo pedido: `auto` publica Release + npm via Actions somente no builder verificado e faz commits + push no consumidor; `apenas commits` e `deploy com release` são overrides, não preferência permanente. `prepare`, discussão ou negação não publicam. Preserve trabalho, index, causalidade, SHA, integridade e autorização; nunca faça staging amplo, force, publique segredos ou inclua feature alheia. O procedimento de refs, checks, versão, rollback e publicação está na skill canônica; gates densos do pacote ficam na release, com testes por impacto antes dela, sem teto de relógio da Task.
 - 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.
-- Ciclo de release: `.agents/config/release-cycle.json` define a versão `major.minor` corrente e `open|frozen`. PRD/SPEC futura pode permanecer `draft`; `ready`, `execute` e início de Task exigem alvo corrente explícito. Para cortar release, encerre Tasks correntes, reconcilie fronts, congele o ciclo e audite SHA/main/branches/worktrees. Execute os checks locais fixos no SHA candidato; publique apenas `main` e exija CI remoto bem-sucedido para esse mesmo SHA antes da Release. Nunca crie branch remota candidata para commit crítico ou release. Exceção única de coordenação do corte requer `release_task_id` e `release_run_id` explícitos no manifesto frozen, Task crítica em execução com alvo corrente, Run raiz ativa e escopos só de release no `freeze`. Antes de `audit`, finalize essa Task/Run, integre seus records no SHA final e mantenha o checkout limpo; `audit` e `advance` revalidam ambos no SHA exato. Após Release e CI exatas observadas, avance a versão com histórico; falha mantém bloqueio e trabalho recuperável.
+- Ciclo de release: `.agents/config/release-cycle.json` define a versão `major.minor` corrente e `open|frozen`; início exige alvo corrente, futuros ficam draft. Reconcilie frentes, encerre trabalho corrente, congele e audite SHA/main/branches/worktrees. Checks locais precedem push somente de `main`; CI verde no SHA precede Release. Nunca crie branch remota candidata. A exceção da coordenação exige Task crítica e IDs explícitos no frozen. Coordenação simples com escopos só de release conclui Task/Run antes de `audit`. Raiz delivery com `--integrated-task` registra `release_mode: integrated_task` e escopo da configuração; ou coordenação delegada de SPEC com ancestralidade/predecessores validados: nesses modos Task executando e Run ativa atravessam `audit`/`advance`, com records exigidos no SHA limpo e exclusão só da coordenação declarada. Após provas de publicação, complete Evidence/revisão aplicável/Gui e persista fechamento; metadata posterior não muda produto/tag. Avance só com Release/CI exatas e demais Tasks terminais; falha preserva bloqueio recuperável. Detalhes no guia 26, seção de ciclo corrente.
 - 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 @@
-4.7.0
+4.9.0