@zaip-ai/cli 2.2.0 → 3.0.0

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: "2.2.0"
+source_release: "3.0.0"
 ---
 
 # 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: 24
+version: 26
 source_change: null
-source_release: "2.2.0"
+source_release: "3.0.0"
 ---
 
 # Work lifecycle
@@ -25,7 +25,7 @@ O ZAIP-AIOS deve aceitar trabalho iniciado por Task, SPEC ou PRD, mantendo PRD e
 - `AC-WORK-001-06`: `conversation start|finish` coordena Executions e Runs idempotentes quando `client_turn_id` é observável; quando indisponível, cada captura usa uma identidade local única. O fluxo permite término sem Task e atualiza a projeção sem exigir comandos manuais intermediários.
 - `AC-WORK-001-07`: pergunta, análise pontual e classificação ausente ou de baixa confiança usam fallback `conversation`, nunca criam Task e preservam telemetria do Run.
 - `AC-WORK-001-08`: continuação, resposta a pergunta do agente, aprovação, refinamento e rework reutilizam o alvo explícito ou o último foco válido da mesma thread; não consultam trabalho global e não criam Task adicional salvo pedido explícito.
-- `AC-WORK-001-09`: edição persistente do repositório, novo resultado independente ou pedido explícito de nova Task cria exatamente uma Task `draft`, sua Change `draft`, uma Execution `delivery` e uma Run raiz `zaip-agent-orchestrator` antes de qualquer mutação; prepare e execute promovem e reutilizam esses mesmos agregados. Draft de PRD/SPEC é exceção de definição: “pensar”, “explorar” ou “ajudar com” permanece Conversation, enquanto “criar” valida o pacote antes da escrita e persiste PRD/SPEC, SPECs técnicas selecionadas e PreparedPlan com criação exclusiva por arquivo e rollback compensatório em caso de falha, sem prometer transação atômica multiarquivo contra interrupção abrupta e sem Task, Change ou Execution `delivery`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo são agregados somente quando observados ou reconciliados e permanecem indisponíveis quando ausentes. A descoberta usa até cinco perguntas críticas por turno e no máximo três turnos; depois assume e registra decisões delegáveis, sem presumir autoridade externa/destrutiva, credencial, obrigação legal ou risco de segurança. Uma nova SPEC só existe para capacidade paralela e independentemente verificável, com contrato estável, sem dependência ou write scope conflitante entre SPECs; dependências ficam na DAG interna. `ready`, inclusive aliases de finalizar/concluir em `draft|ready`, lapida e materializa Changes, Tasks e Execution como `planned`, sem iniciar; toda Task `planned` nunca iniciada ou tentada aparece em Pronto para Executar, avulsa ou vinculada a SPEC. `execute` inicia o menor grão nomeado. Finalizar implementação em `active|verifying` continua Tasks e gates. `desenvolver|melhorar|aprimorar` planeja/refina/retrabalha; PRD cancelado permanece imutável e gera sucessor `draft`, tag `rework` e `rework_of_prd_id`. Cada `client_turn_id` observável possui claim exclusivo e resolve global e atomicamente para exatamente uma Execution `interaction|delivery`; sem ID observável, cada captura recebe identidade local única. Reuso exige kind e origem compatíveis; kind e elegibilidade declarada no catálogo são persistidos. Em `delivery` ou `interaction` com descendente delegado, ao menos uma Sub-Run executora elegível é exigida e o encerramento ocorre somente após `zaip-agent-finalizer` ser o último filho concluído; `interaction` read-only sem descendentes conclui após a resposta sem filhos. `agent-task-finalizer` é aceito apenas na leitura histórica; write scopes ausentes permanecem vazios e título e objetivo são sínteses semânticas fornecidas pela IA.
+- `AC-WORK-001-09`: edição persistente do repositório, novo resultado independente ou pedido explícito de nova Task cria exatamente uma Task `draft`, sua Change `draft`, uma Execution `delivery` e uma Run raiz `zaip-agent-orchestrator` antes de qualquer mutação; prepare e execute promovem e reutilizam esses mesmos agregados. Draft de PRD/SPEC é exceção de definição: “pensar”, “explorar” ou “ajudar com” permanece Conversation, enquanto “criar” valida o pacote antes da escrita e persiste PRD/SPEC, SPECs técnicas selecionadas e PreparedPlan com criação exclusiva por arquivo e rollback compensatório em caso de falha, sem prometer transação atômica multiarquivo contra interrupção abrupta e sem Task, Change ou Execution `delivery`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo são agregados somente quando observados ou reconciliados e permanecem indisponíveis quando ausentes. A descoberta usa até cinco perguntas críticas por turno e no máximo três turnos; depois assume e registra decisões delegáveis, sem presumir autoridade externa/destrutiva, credencial, obrigação legal ou risco de segurança. Uma nova SPEC só existe para capacidade paralela e independentemente verificável, com contrato estável, sem dependência ou write scope conflitante entre SPECs; dependências ficam na DAG interna. `ready`, inclusive aliases de finalizar/concluir em `draft|ready`, lapida e materializa Changes, Tasks e Execution como `planned`, sem iniciar; toda Task `planned` nunca iniciada ou tentada aparece em Pronto para Executar, avulsa ou vinculada a SPEC. `execute` inicia o menor grão nomeado. Finalizar implementação em `active|verifying` continua Tasks e gates. `desenvolver|melhorar|aprimorar` planeja/refina/retrabalha; PRD cancelado permanece imutável e gera sucessor `draft`, tag `rework` e `rework_of_prd_id`. Cada `client_turn_id` observável possui claim exclusivo e resolve global e atomicamente para exatamente uma Execution `interaction|delivery`; sem ID observável, cada captura recebe identidade local única. Reuso exige kind e origem compatíveis; kind e elegibilidade declarada no catálogo são persistidos. Em `delivery` ou `interaction` com descendente delegado, exige-se execução elegível e o encerramento ocorre somente após `zaip-agent-finalizer` ser o último filho concluído. Somente uma raiz Task `delivery` com identidade observada e referência humana explícita persistida em `direct_execution_authorization` desde a captura pode substituir a Sub-Run executora por execução direta; essa alternativa não se aplica a macro ou filho, não pode ser concedida retroativamente e não dispensa Evidence, revisão independente aplicável, Gui nem decisão persistida; `interaction` read-only sem descendentes conclui após a resposta sem filhos. `agent-task-finalizer` é aceito apenas na leitura histórica; write scopes ausentes permanecem vazios e título e objetivo são sínteses semânticas fornecidas pela IA.
 - `AC-WORK-001-10`: a decisão de intake registra intenção, origem, confiança e motivos compactos no Run sem armazenar prompt, segredo ou raciocínio interno.
 - `AC-WORK-001-11`: salvo a exceção de definição de PRD/SPEC `draft` descrita em `AC-WORK-001-09`, qualquer mutação persistente intencional no repositório ou no PC exige Task materializada e Run raiz de orquestração antes da primeira escrita. Também são isentos apenas publicação Git/deploy sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis; editar código, documentação ou configuração ZAIP nunca é isento.
 - Para pedido explícito no turno de `deploy|push|publicar|publicação GitHub`, a publicação Git-only inclui a reconciliação segura da branch/worktree selecionados e commits funcionais do diff pendente pretendido/evidenciado. Essa exceção não cria nem fabrica IDs de PRD/SPEC/Task: quando inexistentes, o commit é funcional sem trailers `ZAIP-*`; quando existentes, a linhagem real é preservada. A exceção exige pathspecs explícitos e verificação, e nunca permite `git add -A`, force, segredos ou worktrees alheios.
@@ -70,11 +70,11 @@ PRDs e SPECs devem permanecer no estágio em que foram criados até uma solicita
 
 ## REQ-WORK-006 — Convergência terminal entre Run e trabalho
 
-Cada Execução ZAIP possui uma Invocação do Orquestrador. `interaction` read-only sem descendentes conclui depois da resposta entregue sem invocações delegadas; interaction com descendente delegado e `delivery` possuem ao menos uma Invocação Delegada executora elegível pelas capacidades do catálogo e exatamente uma Invocação Delegada finalizadora, enquanto SPEC e PRD agregam suas Tasks e permanecem abertos até seus gates parentais.
+Cada Execução ZAIP possui uma Invocação do Orquestrador. `interaction` read-only sem descendentes conclui depois da resposta entregue sem invocações delegadas; interaction com descendente delegado e `delivery` exigem executor elegível pelas capacidades do catálogo, exceto a alternativa direta estritamente definida em `AC-WORK-001-09`, e exatamente uma Invocação Delegada finalizadora, enquanto SPEC e PRD agregam suas Tasks e permanecem abertos até seus gates parentais.
 
 - `AC-WORK-006-01`: uma Run raiz de `orchestration` governa exatamente uma tentativa de Task e permanece aberta enquanto seus Sub-Runs executam; antes de a Run terminar, a Task deve estar `completed`, `blocked`, `failed` ou `cancelled`. `executing` e `verifying` nunca são estados válidos no fim da tentativa.
 - `AC-WORK-006-02`: `RUN-*` continua a chave física compatível do ledger, mas representa uma Invocação de Agente. `parent_run_id: null` e `invocation_kind: orchestrator` identificam exclusivamente a Invocação do Orquestrador; toda Invocação Delegada exige pai, raiz e profundidade positivos. Valores históricos permanecem legíveis e são normalizados na borda. A invocação raiz não pode terminar enquanto qualquer descendente estiver ativo.
-- `AC-WORK-006-03`: em `delivery` ou interaction com descendente delegado, o último filho é um Sub-Run `finalization` executado por `zaip-agent-finalizer`. Ele só inicia depois que um executor elegível e os demais descendentes terminam, impede novos filhos e retorna uma decisão restrita; reviewer, auditor e integrator são permitidos antes da barreira. Quando o host observa o evento terminal, pai, agent_path e identidade catalogada, mas não expõe session/turn filhos, a captura terminal idempotente é permitida somente para o finalizador ou para executor elegível a delivery com capacidade `task-delivery`, exigindo `parent-agent-id` e `parent-run-id` da raiz ativa exata, além de agent_path terminado no `codex_task_name` canônico, e mantendo session, turn, modelo, provider e usage indisponíveis. Uma `interaction` read-only sem descendentes não inicia filhos e a CLI a conclui deterministicamente após a resposta entregue.
+- `AC-WORK-006-03`: em `delivery` ou interaction com descendente delegado, o último filho é um Sub-Run `finalization` executado por `zaip-agent-finalizer`. Ele só inicia depois que todos os descendentes existentes terminam, impede novos filhos e retorna uma decisão restrita. O resultado `completed` exige executor elegível ou a autorização direta válida de `AC-WORK-001-09`, além dos demais gates. Sem executor ou autorização válida, Gui pode avaliar e devolver `blocked`/`failed`, mas não conceder sucesso; não se cria executor cerimonial para contornar a barreira; reviewer, auditor e integrator são permitidos antes da barreira. Quando o host observa o evento terminal, pai, agent_path e identidade catalogada, mas não expõe session/turn filhos, a captura terminal idempotente é permitida somente para o finalizador ou para executor elegível a delivery com capacidade `task-delivery`, exigindo `parent-agent-id` e `parent-run-id` da raiz ativa exata, além de agent_path terminado no `codex_task_name` canônico, e mantendo session, turn, modelo, provider e usage indisponíveis. Uma `interaction` read-only sem descendentes não inicia filhos e a CLI a conclui deterministicamente após a resposta entregue.
 - `AC-WORK-006-04`: uma Run raiz de SPEC/PRD pode terminar sem terminalizar o macro. O pai passa a `active` quando uma Task filha inicia, permanece em Execução durante intervalos e só entra em Verificação depois de todas as Tasks concluírem; delivery exige gates parentais próprios.
 - `AC-WORK-006-05`: status técnico de Run/Sub-Run (`completed`, `failed`, `cancelled`) é independente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`); a orquestração pode concluir tecnicamente e bloquear a Task por falha de gate.
 - `AC-WORK-006-06`: continuação não preserva Task em `executing` ou `verifying`, e fechamento da tentativa não pode ser adiado. Retomada de `blocked` usa `resume`; `failed` usa `rework` na mesma Task e incrementa a tentativa; `completed` e `cancelled` são imutáveis.
@@ -92,7 +92,7 @@ Cada Execução ZAIP possui uma Invocação do Orquestrador. `interaction` read-
 
 Cada Task concluída com mutação deve possuir um commit canônico isolado e publicável sem reorganização no momento do deploy.
 
-- `AC-WORK-007-01`: o assunto usa o provider efetivo exclusivamente `CODEX` ou `CLAUDE` e não contém `AUTO`; em linhagem evidenciada usa blocos opcionais `[P:XXXX] [S:XXXX] [T:XXXX]`, Task sem PRD/SPEC usa `[Task-first:XXXX]` e commit funcional sem Task usa `[CODEX] <título funcional>` sem `ZAIP-Task`. Referências têm quatro caracteres do alfabeto ZAIP, blocos e trailers sem evidência são omitidos, o assunto nunca excede 96 caracteres e somente o título pode ser reduzido em limite de palavra.
+- `AC-WORK-007-01`: commit de produto exige Task real, título canônico e provider efetivo `CODEX` ou `CLAUDE`, nunca `AUTO`; linhagem evidenciada usa blocos opcionais `[P:XXXX] [S:XXXX] [T:XXXX]`, Task sem PRD/SPEC usa `[Task-first:XXXX]`. Referências têm quatro caracteres do alfabeto ZAIP; blocos e trailers sem evidência são omitidos. Assunto ≤96 caracteres, somente título reduzido por palavra. Task/Change/Execution devem existir na árvore do commit, estar causalmente vinculadas e cobrir seus caminhos por write scopes. Hook valida o índice real; CI valida cada SHA novo após marco explícito, sem retroagir. Somente diff restrito a `.agents/records/**` e `.local/**` dispensa identidade; renomeações incluem origem e destino, arquivos ignorados já rastreados continuam sujeitos à política. Conversas preservam telemetria e não disparam commits. Merge/revert/bot não têm exceção pelo texto; nunca selecionar a última Task global.
 - `AC-WORK-007-02`: o corpo contém trailers `ZAIP-PRD`, `ZAIP-SPEC`, `ZAIP-Task`, `ZAIP-Change`, `ZAIP-Execution` e `ZAIP-Agent` com identificadores completos, omitindo apenas os ancestrais inexistentes; o commit de integração também registra `ZAIP-Product-Commit`.
 - `AC-WORK-007-03`: a integração recusa worktree pendente, mensagem não canônica, Task divergente, arquivo fora do write scope ou conflito; uma Task aprovada produz um merge `--no-ff` com a mesma atribuição canônica, preservando o candidato validado.
 - `AC-WORK-007-04`: pedido explícito de deploy/push é Git-only e autoriza reconciliar com segurança somente a branch e o worktree selecionados, além de particionar o trabalho pendente pretendido/evidenciado em commits funcionais com pathspecs explícitos. Sem IDs de PRD/SPEC/Task, não os fabrica nem inclui trailers `ZAIP-*`; nunca executa `git add -A`, adiciona feature não relacionada, combina grupos, reescreve histórico, força push, expõe segredo ou faz squash da hierarquia.

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: "2.2.0"
+source_release: "3.0.0"
 ---
 
 # Evidências, custo por Task e autonomia por SPEC

package/templates/.agents/rules/architecture.md

@@ -5,6 +5,8 @@ priority: critical
 max_context_tokens: 1000
 requires:
   - RULE-CORE
+triggers: [arquitetura, architecture, modularização, modularization, cqrs]
+domains: [arquitetura, architecture, modularização, modularization, cqrs]
 ---
 
 # Arquitetura, desenvolvimento e CQRS canônicos

package/templates/.agents/rules/astra-diagnostic.md

@@ -2,13 +2,15 @@
 id: RULE-ASTRA-DIAGNOSTIC
 load: manual
 priority: high
-max_context_tokens: 650
+max_context_tokens: 950
 requires:
   - RULE-CORE
 ---
 
 # Astra para diagnóstico difícil
 
+Para Tasks com política congelada `autonomy-v1`, prevalece `RULE-AUTONOMY-DECISION`: Essencial proíbe Astra automático; Equilibrado usa Sol/high no primeiro replanejamento e Astra/high no segundo/terceiro, permitindo execução Astra/high no terceiro bloco; Persistente não tem quota total. As restrições abaixo são o contrato legado e não podem reintroduzir seu teto ou proibição de execução no perfil novo.
+
 Carregue somente ao avaliar uma escalada Astra. Luna/Terra executam trabalho comum; Sol continua responsável pela faixa difícil. Marketing, Sales, Growth, Ops, título, palavras como “crítico”, volume ou número de arquivos não justificam Astra.
 
 - Entrada: origem automática autorizada, dificuldade estruturada (complexidade alta ou ambiguidade alta) e evidência de uma tentativa executora que falhou por hipótese/raciocínio. Exceção preventiva: impacto material crítico comprovado e diagnóstico difícil comprovado. Erros de ambiente, credenciais, ferramentas, sintaxe ou falta de evidência não autorizam a escalada.

package/templates/.agents/rules/autonomy-decision.md

@@ -2,9 +2,11 @@
 id: RULE-AUTONOMY-DECISION
 load: auto
 priority: high
-max_context_tokens: 500
+max_context_tokens: 1600
 requires:
   - RULE-CORE
+triggers: [autonomia, autonomy, autorização, authorization, credencial, credential]
+phases: [conversation, definition, planning, execution]
 ---
 
 # Decisao autonoma proporcional
@@ -12,4 +14,12 @@ requires:
 - Aja por padrao somente quando a acao for reversivel, estiver dentro do escopo e a evidencia permitir uma decisao tecnica delegavel.
 - Pergunte quando uma escolha humana alterar materialmente objetivo, custo, autoridade, dados externos ou o risco aceito.
 - Antes de classificar uma credencial como lacuna, aplique `$zaip-skill-local-credentials` à ação já autorizada. Bloqueie e registre razão sanitizada somente após a busca limitada resultar em credencial ausente, ambígua ou inutilizável, ou quando faltar autorizacao externa/destrutiva, requisito legal/seguranca, ou evidencia factual necessaria; nunca invente dados, resultados ou chaves de configuracao.
-- O limite `execution.autonomous.max_total_invocations` e um circuito finito: ao atingi-lo, pare com estado resumivel e evidencia do motivo; nao reinicie nem contorne o contador.
+- Com `autonomy.version: 1`, aplique o perfil congelado por Task estável: `essential` (Essencial) = 1 execução inicial + 3 reparações e 1 replanejamento Sol/high; `balanced` (Equilibrado, padrão de novas configurações) = 1 inicial + 9 reparações e 3 replanejamentos (Sol/high, Astra/high, Astra/high). Cada replanejamento libera até 3 reparações. Não existe quarto replanejamento no Equilibrado.
+- `persistent` (Persistente — ilimitado) é opt-in: não tem teto de tentativas, replanejamentos ou invocações agregadas. Pode continuar indefinidamente até cancelamento humano. Mantém permissões e critérios de aceite. Não reintroduza quotas legadas de 3, 10 ou 24 nesse perfil.
+- Essencial nunca seleciona Astra automaticamente, inclusive por herança, fallback ou subagentes. A única exceção é o principal de uma Task avulsa com Astra escolhido manualmente pelo usuário no host. Nos demais perfis, Astra/high pode também executar no bloco iniciado pelo terceiro replanejamento, sem ampliar o orçamento.
+- Task avulsa preserva modelo/esforço do principal e prioriza trabalho direto. Delegue só por necessidade concreta. Antes da delegação, informe que subagentes seguem a política ZAIP e podem usar modelo/esforço diferentes; registre a configuração observada, mantendo desconhecidos explícitos. Não prometa override que o host não suporta.
+- Reserve no ledger persistente da Task antes da invocação e registre o resultado observado. Tool calls, testes individuais, tokens e relógio não são tentativas. Uma retomada não renova orçamento; mudança de configuração só vale para novas Tasks. Não invente contagens históricas numa migração.
+- Não abandone por duração. Limites técnicos de uma ferramenta não provam falha do produto. Recuperações internas e replanejamentos inválidos não podem criar chamadas de IA fora do controle de orçamento. Ausência de decisão Gui não é aprovação; persista decisão real e depois Stop, ou use o relay atômico suportado na captura.
+- Ao esgotar recuperação: `failed` exige impedimento técnico comprovado; falta de verificação, acesso, evidência ou conclusão segura é `blocked`. Preserve entrega parcial e liste ACs pendentes; nunca reduza ACs automaticamente. Continue ramos independentes da DAG, mas não execute dependentes de Task não concluída.
+- Perfil controla persistência, não rigor: engenharia comprova comportamento e segurança; conteúdo comprova fidelidade às fontes e briefing; estratégia/operações comprovam dados e premissas. Risco define assurance, não o domínio sozinho.
+- Configurações legadas sem `autonomy` mantêm seus limites anteriores até adoção explícita. O limite legado `execution.autonomous.max_total_invocations` não é um segundo teto em `autonomy-v1`. Garantia determinista exige o ponto de dispatch gerenciado: prompt ou captura posterior de ferramentas nativas, isoladamente, não impede chamadas fora dele.

package/templates/.agents/rules/cloud-hostinger-autonomy.md

@@ -6,6 +6,8 @@ max_context_tokens: 1000
 requires:
   - RULE-CORE
   - RULE-SECURITY
+triggers: [terraform, hostinger, cloudflare, "ssh de infraestrutura", "infrastructure ssh"]
+domains: [terraform, hostinger, cloudflare, ssh]
 ---
 
 # Cloudflare, Hostinger e Terraform

package/templates/.agents/rules/context.md

@@ -2,9 +2,10 @@
 id: RULE-CONTEXT
 load: auto
 priority: high
-max_context_tokens: 650
+max_context_tokens: 450
 requires:
   - RULE-CORE
+triggers: [contexto, context, tokens, "context pack"]
 ---
 
 # Contexto e economia de tokens canônicos

package/templates/.agents/rules/core.md

@@ -2,16 +2,27 @@
 id: RULE-CORE
 load: always
 priority: critical
-max_context_tokens: 760
+max_context_tokens: 1400
 requires: []
 ---
 
 # Contexto e autoridade
 
+## Proteção do computador local
+
+- Nunca reinicie, desligue, suspenda, hiberne ou encerre a sessão do computador local do usuário (Windows ou outro SO). A proibição vale para comandos diretos, APIs, scripts, instaladores, tarefas agendadas, ferramentas gráficas, agentes e subagentes; acesso total, autonomia, recuperação e autorização de instalação não concedem exceção.
+- Não execute `Restart-Computer`, `Stop-Computer`, `shutdown.exe`, `Restart-Host`, chamadas WMI/CIM `Win32Shutdown`/`Reboot`, `reboot`, `poweroff`, `halt` ou equivalentes com esse efeito. Não contorne a regra usando outro shell, processo, serviço, API ou máquina para atingir o host local.
+- Antes de instalar/atualizar dependências, inspecione o comando e os scripts chamados. Use opções documentadas que suprimam reinício automático (por exemplo, `/norestart` ou `REBOOT=ReallySuppress` quando suportadas); nunca habilite `--allow-reboot`. Se não puder garantir execução sem reinício, não execute essa etapa.
+- Reinício necessário ou pendente deve ser relatado e deixado exclusivamente à ação manual do usuário. Não agende, confirme diálogos nem execute reinício como teste de validação. Testes desta política são estáticos ou simulados.
+- Reiniciar um processo específico do projeto não significa reiniciar o SO: identifique o processo e preserve o escopo autorizado. Reinício de servidor remoto exige alvo remoto inequívoco e autorização própria; nunca use o computador local como fallback.
+- Inclua esta restrição em toda delegação que possa executar comandos. Todas as skills e automações obedecem a esta regra, inclusive setup, diagnóstico e recuperação.
+
+## Fluxo e autoridade
+
 - Leia `.agents/config/project.yaml`; aplique ZAIP somente com `zaip.enabled: true` booleano. Carregue Rules `always`, Rules aplicáveis e seus pré-requisitos, Requirements/AC governantes e skills canônicas pertinentes. Reutilize contexto inalterado; descubra trabalho pelos manifests e leia records somente por ID explícito, sem varrer histórico.
-- Capture uma vez: perguntas, explicações e análises são `conversation`; continuação/refinamento/rework usa somente o foco da mesma `client_thread_id`; trabalho persistente independente é `new-work` com título semântico. Não associe pergunta simples à primeira Task global. Uma `interaction` read-only sem descendentes responde diretamente e termina após a resposta, sem Task/Change, executor ou finalizador artificiais.
-- Antes de criar/refinar artefatos, executar entrega ou delegar, carregue `RULE-WORKFLOW`, `RULE-RUN-LIFECYCLE-CLOSURE` e a skill de execução aplicável. Pensar PRD/SPEC não cria artefatos; criação draft exige pedido explícito e `ready|execute` materializa DAG. Antes de mutação independente materialize Task, Change, Execution `delivery` e Run raiz; exceções Git-only, telemetria, cache/build/teste e temporários seguem workflow. Código, configuração e documentação são produto.
-- Antes de delegar, leia `RULE-SPECIALIST-ROUTING` e catálogo: raiz despacha `zaip-agent-orchestrator`, único dispatcher dos executores elegíveis; último filho `zaip-agent-finalizer`, após todos terminarem. Use somente `spawn_agent` nativo e os exatos `codex_name`/`codex_task_name`; `create_thread|fork_thread` exigem pedido de chat independente. Nunca invente ancestralidade; capture eventos reais, campos ausentes ficam indisponíveis. Detalhes obrigatórios: `.agents/skills/zaip-skill-execution/references/runtime-governance.md`.
+- Capture uma vez: perguntas, explicações e análises são `conversation`; continuação/refinamento/rework usa somente o foco da mesma `client_thread_id`; trabalho persistente independente é `new-work`. Não associe pergunta simples à primeira Task global. Uma `interaction` read-only sem descendentes responde diretamente e termina após a resposta, sem Task/Change, executor ou finalizador artificiais. O ciclo completo, demais exceções e fechamento pertencem a `RULE-WORKFLOW` e `RULE-RUN-LIFECYCLE-CLOSURE`.
+- Antes de criar/refinar artefatos, executar entrega ou delegar, carregue `RULE-WORKFLOW`, `RULE-RUN-LIFECYCLE-CLOSURE` e a skill de execução aplicável. Antes de delegar, leia `RULE-SPECIALIST-ROUTING` e o catálogo. Use somente `spawn_agent` nativo e os exatos `codex_name`/`codex_task_name`; `create_thread|fork_thread` exigem pedido de chat independente. Detalhes de runtime: `.agents/skills/zaip-skill-execution/references/runtime-governance.md`.
 - Preserve escopo, permissões, fontes e alterações alheias. Antes de ação externa, destrutiva ou irreversível verifique autorização vigente; credenciais autorizadas seguem `zaip-skill-local-credentials`, sem expor valores. Nunca invente fatos, custos, tokens, Evidence, testes ou resultados. Separe estimativa de observação e incerteza de conclusão.
 - Selecione esforço pela operação, capacidade e ambiguidade, não pelo departamento. Pergunta simples de Marketing/Sales/Growth/Ops não carrega engenharia, Change ou Meta Ads sem necessidade. Modelo/effort são imutáveis por Run; respeite seleção manual do host e origens automáticas configuradas. No modo manual leia `RULE-MODEL-ORCHESTRATION`. Desenvolvimento carrega também arquitetura, segurança e contexto técnico pertinente; entrega comercial mantém assurance proporcional.
 - Pergunte só o necessário, até cinco perguntas por turno e três turnos, respeitando autorização já dada. Plano opcional de até cinco passos usa `DEFINE:`, `PLAN:`, `EXECUTE:`, `VERIFY:`.
+- Deploy GitHub explícito seleciona `$zaip-skill-github-deploy`: frontend/backend seguem a branch configurada, inclusive `main`; banco exige `beta` e promoção humana. No framework, tag `vN.N` corresponde ao pacote `N.N.0`; só GitHub Actions publica `@zaip-ai/cli` no npm.

package/templates/.agents/rules/design-system-central-contract.md

@@ -0,0 +1,17 @@
+---
+id: RULE-DESIGN-SYSTEM-CENTRAL
+load: file_match
+priority: critical
+max_context_tokens: 500
+requires: [RULE-CORE]
+globs: [".agents/design/DESIGN.md", ".agents/design/tokens/**", ".agents/design/apps/catalog/**", ".agents/design/packages/**"]
+---
+
+# Contrato central do design system
+
+- O ZAIP-AIOS instala o design system padrão; toda solicitação posterior do usuário para criar ou editar o design system personaliza o contrato central do projeto, sem cópias paralelas.
+- Sem exceção, a Change atualiza em conjunto `.agents/design/DESIGN.md`, os tokens pertinentes, espécimes, stories e testes pertinentes, e o frontend real de `.agents/design/apps/catalog/src/pages/DesignSystemPage.tsx` e `.agents/design/apps/catalog/src/pages/ComponentsPage.tsx`.
+- `#/design-system` é a página de fundações e tokens; `#/components` é a página de componentes. Ambas consomem a mesma fonte central, documentam a mudança e passam pela prova renderizada antes de a entrega ser declarada pronta.
+- Componentes e tokens globais têm representação renderizável no frontend real `#/components`, com exemplo e estados ou variantes aplicáveis. Todo componente local novo também tem representação renderizável ali, sem transformar sua lógica ou token em global. A atualização conjunta de `.agents/design/DESIGN.md`, tokens e das duas páginas do catálogo só é exigida ao mudar o contrato central.
+- `#/components` e seus espécimes refletem a identidade vigente de `.agents/design/DESIGN.md` — cor, tipografia, espaçamento, raios, bordas e estados — com os tokens pertinentes. Sincronize fontes, código e builds distribuíveis que a mudança afetar.
+- Atualize consumidores afetados; para mudança incompatível, registre a migração e os consumidores responsáveis na Change. Um requisito isolado de produto não cria token ou componente global sem reutilização comprovada.

package/templates/.agents/rules/evolution.md

@@ -2,9 +2,11 @@
 id: RULE-EVOLUTION
 load: auto
 priority: high
-max_context_tokens: 550
+max_context_tokens: 425
 requires:
   - RULE-WORKFLOW
+triggers: [evolução, evolution, framework, migration, migração]
+phases: [planning, execution, verification, evidence]
 ---
 
 # Evolução governada canônica

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,26 @@
 id: RULE-RUN-LIFECYCLE-CLOSURE
 load: auto
 priority: critical
-max_context_tokens: 840
+max_context_tokens: 1200
 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.
-- 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.
+- Toda Execution tem raiz `zaip-agent-orchestrator`. Interaction read-only sem descendentes conclui após resposta sem executor/finalizador; delegada e delivery aguardam a árvore. Sucesso exige executor elegível ou raiz Task direta com `--direct-authorization` explícita desde captura e turno/modelo observados, além de Evidence e Gui. Gui pode avaliar bloqueio/falha sem executor; `executor_missing` impede completed, não o registro verdadeiro de inconclusão.
+- Cada tentativa de Task tem um orquestrador responsável; ao terminar, concilia `completed`, `blocked`, `failed` ou `cancelled`. Falha de persistência mantém recibo recuperável, nunca sucesso fictício. Terminar executor não termina Task.
+- Se a raiz física já possui a Task, ela é esse responsável e despacha executor/revisor e Gui diretamente, sem Dave adicional. Uma raiz macro delega um orquestrador por Task; não cria outro proprietário para a mesma tentativa.
+- Raiz física tem `run_role: orchestrator`, pai nulo/profundidade zero. Orquestrador de Task delegado preserva `run_role: subagent`, propósito `orchestration` e ancestralidade real; papel de agente não redefine raiz física.
+- Em delivery e interaction delegada, o último filho é exatamente um Sub-Run do `zaip-agent-finalizer` do orquestrador responsável, irmão dos executores, nunca filho deles. Aguarda descendentes; sua barreira impede novos Sub-Runs. Fechamento parental é separado.
 - 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.
+- Gui read-only não precisa permanecer vivo esperando recibo. O host pode transmitir sua decisão real em `subagent capture --event stop` com `--task-outcome`, `--summary`, `--evidence` e `--changed-files`: a CLI autentica a identidade rica e persiste a decisão imutável antes de Stop/fechamento. Aceita Gui já terminal apenas enquanto o responsável está aberto; responsável fechado aceita somente replay da decisão já existente, não nova aprovação. Ausência de decisão continua fail-closed.
+- Use `completed` somente com gates e Evidences aprovados; `blocked` para dependência externa, autoridade ou informação ausente, gate/teste pendente, falta de Evidence ou outra inconclusão após recuperação. Duração não determina abandono. 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. 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-*` 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`.
 - 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.
+- Novos projetos usam `execution.runtime: managed`: PRD/SPEC gerenciados, avulsas diretas. Ausente/manual não invoca provider; autonomous permite também Task gerenciada explícita. 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|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
+3.0.0