@zaip-ai/cli 4.9.0 → 5.1.0

package/templates/.agents/design/apps/catalog/dist/index.html

@@ -5,7 +5,7 @@
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
     <meta name="description" content="Design system e catálogo de componentes do repositório ZAIP." />
     <title>ZAIP Design System</title>
-    <script type="module" crossorigin src="./assets/index-D3uhpycC.js"></script>
+    <script type="module" crossorigin src="./assets/index-BGxXxXTo.js"></script>
     <link rel="stylesheet" crossorigin href="./assets/index-D1JaPXfV.css">
   </head>
   <body>

package/templates/.agents/design/apps/catalog/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zaip-ai/design-catalog",
-  "version": "4.9.0",
+  "version": "5.1.0",
   "private": true,
   "type": "module",
   "scripts": {

package/templates/.agents/design/apps/catalog/src/components/TopEntitiesSpecimen.tsx

@@ -0,0 +1,45 @@
+import { useState } from "react";
+import { Button, Card } from "./Primitives.js";
+
+const fixtures = {
+  task: { label: "Tarefas", id: "TASK-EXEMPLO", title: "Implementar navegação" },
+  spec: { label: "SPECs", id: "SPEC-EXEMPLO", title: "Navegação do dashboard" },
+  prd: { label: "PRDs", id: "PRD-EXEMPLO", title: "Rastreabilidade do trabalho" },
+} as const;
+
+/** Native catalog adapter: production routing remains in OperationsOverviewTopPanel. */
+export function TopEntitiesSpecimen() {
+  const [kind, setKind] = useState<keyof typeof fixtures>("task");
+  const [selected, setSelected] = useState<string | null>(null);
+  const item = fixtures[kind];
+  return (
+    <Card>
+      <section className="specimen-row" aria-label="Tipo de item do Top 5">
+        {Object.entries(fixtures).map(([value, fixture]) => (
+          <Button
+            key={value}
+            aria-pressed={kind === value}
+            onClick={() => {
+              setKind(value as keyof typeof fixtures);
+              setSelected(null);
+            }}
+          >
+            {fixture.label}
+          </Button>
+        ))}
+      </section>
+      <p>Top 5 {item.label}: mouse, Enter ou Espaço selecionam o item da barra.</p>
+      <Button
+        aria-label={`Abrir detalhes de ${item.title}: 2 h`}
+        onClick={() => setSelected(`${item.id} — ${item.title}`)}
+      >
+        2 h · {item.title}
+      </Button>
+      <p role="status">
+        {selected
+          ? `Destino do popup de rastreabilidade: ${selected}`
+          : "Selecione uma barra para conferir o destino do popup."}
+      </p>
+    </Card>
+  );
+}

package/templates/.agents/design/apps/catalog/src/pages/ComponentsPage.tsx

@@ -34,6 +34,7 @@ import {
   StackVersionFieldSpecimen,
   stackVersionFieldFixtures,
 } from "../components/StackVersionFieldSpecimen.js";
+import { TopEntitiesSpecimen } from "../components/TopEntitiesSpecimen.js";
 import {
   WorkspaceStatusSpecimen,
   workspaceStatusFixtures,
@@ -216,9 +217,10 @@ export function ComponentsPage() {
       </Section>
       <Section
         title="Gráficos"
-        description="Visualizações possuem título descritivo, comparação consistente e alternativa textual."
+        description="Visualizações possuem título descritivo, comparação consistente e alternativa textual. No Top 5, todas as barras de Tarefas, SPECs e PRDs abrem o popup do item selecionado; a troca de modo preserva esse contrato."
       >
         <ChartPanel />
+        <TopEntitiesSpecimen />
       </Section>
       <Section
         title="Carregando, vazio e erro"

package/templates/.agents/design/apps/catalog/src/stories/Components.stories.tsx

@@ -27,6 +27,7 @@ import {
   StackVersionFieldSpecimen,
   stackVersionFieldFixtures,
 } from "../components/StackVersionFieldSpecimen.js";
+import { TopEntitiesSpecimen } from "../components/TopEntitiesSpecimen.js";
 import { ComponentsPage } from "../pages/ComponentsPage.js";
 
 const meta = {
@@ -38,6 +39,7 @@ const meta = {
 export default meta;
 type Story = StoryObj<typeof meta>;
 export const Catalog: Story = {};
+export const TopEntitiesNavigation: Story = { render: () => <TopEntitiesSpecimen /> };
 export const EstimatedCosts: Story = {
   render: () => (
     <div className="metric-grid">

package/templates/.agents/design/packages/local-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zaip-ai/design-local-runtime",
-  "version": "4.9.0",
+  "version": "5.1.0",
   "private": true,
   "type": "module",
   "scripts": {

package/templates/.agents/requirements/autonomous-assurance.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-AUTONOMOUS-ASSURANCE
 area: autonomous-assurance
 title: Garantia adaptativa e execução autônoma
 status: active
-version: 5
+version: 6
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Garantia adaptativa e execução autônoma
@@ -22,6 +22,14 @@ Uma Task avulsa deve provar todos os Acceptance Criteria com profundidade propor
 - `AC-ASSURE-001-05`: uma Task sensível a segurança, migração, irreversibilidade ou múltiplos domínios não pode usar `lite` para contornar controles críticos.
 - `AC-ASSURE-001-06`: somente sob `assurance.version: 1`, uma Task `lite` com `editorial_delivery:true`, `verification_scope:"scoped"`, write scope editorial estreito e candidato textual regular pode dispensar a Decision das seis etapas. Ela ainda exige check tipado real, Evidence tipada cobrindo os ACs, commit/candidato Git, revisão e finalização. Código, configuração, controles de agente, ação externa, dado sensível, migração, risco `standard|critical` ou sinal sensível rejeitam a exceção; qualquer Task sem esse opt-in preserva a Decision.
 
+A rota editorial de `AC-ASSURE-001-06` inclui os literais `README.md` e
+`README-ENG.md`, Markdown literal em `docs/` e subdiretório documental estreito
+como `docs/quality/**`, além das raízes editoriais de negócio existentes.
+`docs/**` amplo não concede exceção. A prova usa o diff Git completo, modo de
+arquivo regular não executável e conteúdo textual; controles de agente,
+código, configuração, links, binários e sinais sensíveis continuam rejeitados.
+Uma alteração nesses controles é mudança de código/regra e conserva seu risco.
+
 ## REQ-ASSURE-002 — Garantia parental para SPEC e PRD
 
 Entregar uma SPEC ou PRD deve exigir prova no nível do produto planejado, além da soma dos testes das Tasks descendentes.
@@ -61,6 +69,7 @@ Aprendizado e alegações de maturidade devem ser derivados de fatos verificáve
 - `AC-EVOL-001-02`: lesson exige finding e locator verificável; opinião isolada não promove Rule, Requirement ou skill.
 - `AC-EVOL-001-03`: maturidade progride sequencialmente por `declared`, `implemented`, `locally_evidenced`, `cleanroom_validated`, `representative_validated` e `production_observed`.
 - `AC-EVOL-001-04`: Evidence de validação referencia o hash exato do candidato; cleanroom e estados posteriores exigem verificador independente, e produção exige Run observado. No runtime autônomo, o candidato é confirmado por Git e por ausência de alterações posteriores de produto no escopo, não somente pelo hash declarado em artefatos. Aprovação independente e Evidence devem referenciar o mesmo candidato. Qualidade conhecida abaixo do piso bloqueia mesmo sem dados de custo disponíveis.
+- No fechamento pós-publicação de `AC-EVOL-001-04`, o SHA validado permanece o candidato original. Um SHA publicado descendente só é aceito se cada commit intermediário, inclusive cada pai de merge, alterar exclusivamente `.agents/records/**`; igualdade final de bytes ou reversão posterior não substitui essa prova. O ciclo deve conter um único append com o SHA publicado exato, e Evidence/Validation selecionadas são vinculadas por hash de conteúdo. Mutação do limite de produto deve falhar no teste isolado.
 
 ## REQ-QUALITY-001 — Gates de release e cobertura sem regressão
 

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

@@ -6,7 +6,7 @@ title: Autonomia delimitada para Cloudflare e Hostinger
 status: proposed
 version: 1
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Cloudflare e Hostinger (proposta de requisito)

package/templates/.agents/requirements/comparative-audit.md

@@ -6,7 +6,7 @@ title: Auditoria comparativa e plano de evolução
 status: active
 version: 1
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Auditoria comparativa e plano de evolução

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

@@ -6,7 +6,7 @@ title: Contexto mínimo, seguro e navegável
 status: active
 version: 9
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Context engine

package/templates/.agents/requirements/cost-observability.md

@@ -6,7 +6,7 @@ title: Tokens, custos e cobertura
 status: active
 version: 10
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Cost observability

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

@@ -6,7 +6,7 @@ title: Inicialização e hidratação confiável do dashboard
 status: active
 version: 1
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Inicialização e hidratação confiável do dashboard

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: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # 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: 5
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Design system

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

@@ -6,7 +6,7 @@ title: Preparação, materialização e DAG
 status: active
 version: 13
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Execution engine

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

@@ -6,7 +6,7 @@ title: Projeções operacionais e analíticas
 status: active
 version: 14
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Kanban and dashboard

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: 10
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # 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: 10
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # 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: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # 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: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Melhorias estratégicas de custo, qualidade e resiliência

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

@@ -6,7 +6,7 @@ title: Ciclo de vida do trabalho
 status: active
 version: 26
 source_change: null
-source_release: "4.9.0"
+source_release: "5.1.0"
 ---
 
 # Work lifecycle
@@ -75,6 +75,7 @@ Cada Execução ZAIP possui uma Invocação do Orquestrador. `interaction` read-
 - `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 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 manutenção autorizada para reparar o fechamento pós-publicação pode emitir recibo canônico na própria Change enquanto sua Run delivery permanece ativa. Após Task de manutenção e Gui terminarem `completed`, a CLI pública consome o recibo somente para a Task/SPEC/Execution histórica exata, com revisões, autorização humana observada, provas de candidato/publicação/CI/ciclo e conteúdo de Evidence revalidados. O claim exclusivo permite uma raiz sucessora da SPEC no mesmo turno observado ou em turno novo autenticamente observado; crash parcial não cria outra raiz ou aprovação. A Task histórica não ganha escrita de produto nem reutiliza o Gui da manutenção: seu fechamento precisa de executor elegível, Evidence e seu último finalizador próprios. Testes de mutação devem matar a remoção da barreira de Gui e da verificação da fronteira de produto.
 - `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.

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

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

@@ -14,6 +14,7 @@ phases: [execution, verification, evidence]
 
 - 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.
+- Retomada pós-publicação exige manutenção e seu último Gui concluídos. O recibo na Change fixa autorização humana, Task/SPEC/Execution, revisões e provas; o consumo revalida publicação, ciclo e proprietário único. O handoff tipado preserva uma raiz ativa por invocação. A Task histórica exige Evidence, revisão aplicável e novo Gui.
 - 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.
@@ -21,7 +22,7 @@ phases: [execution, verification, evidence]
 - 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.
 - 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.
+- Use `failed` somente para erro técnico ou de integridade impeditivo. Tempo, silêncio, escopo incompleto ou gate pendente não são falha técnica; inconclusões são `blocked`. `cancelled` exige pedido humano explícito. Nos fluxos que exigem Gui, o orquestrador terminaliza após sua conclusão.
 - `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/workflow.md

@@ -26,4 +26,5 @@ phases: [planning, execution, verification, evidence]
 - 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`; 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.
+- Fechamento pós-publicação de uma Task histórica bloqueada usa somente `task recover-post-publication` e `task resume-post-publication` com recibo emitido pela Change da manutenção e prova imutável da publicação. O novo responsável recebe a Execution/SPEC original, revisões exatas e claim exclusivo; se a mesma invocação humana continuar após a manutenção terminada com Gui, o handoff tipado preserva ambas as raízes e seus turnos observados. O ciclo já avançado permanece aberto na versão corrente, sem novo grant, refreeze, reetiquetagem de SHA, produto novo ou segunda publicação. Task histórica não recebe claim de escrita de produto; apenas records e o avanço já comprovado podem integrar o fechamento. Guie-se pelo contrato canônico de recuperação da skill execution.
 - 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.9.0
+5.1.0