@zaip-ai/cli 6.2.0 → 7.5.0

package/templates/.agents/dashboard/apps/frontend/dist/assets/CostCalculationGuidePage-DZ2mnR6k.js

@@ -0,0 +1 @@
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-YfoKMzCQ.js";var r=e(t(),1),i=n();function a({locale:e}){let t=e===`pt-BR`;return(0,i.jsxs)(`section`,{className:`cost-guide-section`,children:[(0,i.jsx)(`h2`,{children:t?`Como conferir os totais e a telemetria`:`Reconciling totals and telemetry`}),(0,i.jsx)(`p`,{children:t?`O total geral soma uma vez o custo registrado de cada atividade. Com os mesmos filtros, moeda e snapshot: Conversa + Planejamento + Execução = total geral. Some os valores antes de arredondar: a soma dos cartões arredondados pode diferir por centavos.`:`The grand total counts each activity's recorded cost once. With the same filters, currency and snapshot: Conversation + Planning + Execution = grand total. Sum before rounding; rounded cards can differ by cents.`}),(0,i.jsx)(`p`,{children:t?`A aba Conversas agrupa atividades de todas as fases vinculadas a uma conversa; ela não representa somente a fase Conversa. Seu subtotal + custos sem vínculo + referências sem registro canônico recompõem o total. A mesma regra vale para Tarefas. PRDs e SPECs acumulam atividades dos filhos: não some os níveis do Kanban para conferir o total geral; use o resumo financeiro sem duplicação da exportação.`:`The Conversations tab groups linked activities from all phases, not just the Conversation phase. Its subtotal + unattributed costs + references without a canonical record reconcile to the total. The same rule applies to Tasks. PRDs and SPECs roll up child activities: do not sum Kanban hierarchy levels; use the export's deduplicated financial summary.`}),(0,i.jsx)(`p`,{children:t?`Os números mostram a soma conhecida, sem o sufixo parcial. Quando não há valor registrado, a tela exibe 0 por convenção; isso não prova consumo gratuito. Os registros e as exportações preservam ausência e cobertura. Tokens, custo e duração têm coberturas independentes: contar uma atividade não garante que as três medições foram coletadas. Lacunas de custo continuam interrompendo a linha do gráfico.`:`Numbers show the known sum, without a partial suffix. Missing values display as 0 by convention; this does not prove free usage. Records and exports preserve missing values and coverage. Tokens, cost and duration have independent coverage; counting an activity does not imply all three were measured. Missing costs still break the chart line.`}),(0,i.jsx)(`p`,{children:t?`Tokens só permitem calcular custo quando há modelo, tarifa aplicável, divisão de input/cache/output e conversão de moeda suficientes. Se o catálogo cobra gravação de cache, sua quantidade também é necessária; ausência dessa medição não prova zero. Um valor ausente não deve ser preenchido com tarifa atual sem comprovação histórica. O custo é uma estimativa registrada, não uma fatura do provedor.`:`Pricing tokens requires sufficient model, applicable rates, input/cache/output and currency data. If the catalog charges cache writes, their quantity is also required; missing observations do not prove zero. Missing historical costs must not be filled using today's prices without evidence. Recorded cost is an estimate, not a provider invoice.`}),(0,i.jsx)(`p`,{children:t?`Para conferir dados novos, atualize a página. Se ainda estiverem antigos ou ocorrer erro de carregamento, abra novamente o executável do dashboard e aguarde o carregamento. Novas atividades e coleta em andamento não disparam o aviso vermelho; a consulta de saúde ocorre ao abrir a página, sem repetição a cada cinco segundos.`:`Reload the page to check new data. If it remains old or fails to load, reopen the dashboard executable and wait for loading. New activity and capture in progress do not trigger the red alert; health is checked on page load, not every five seconds.`})]})}var o={input:1e5,cache:4e4,output:2e4,reasoning:8e3},s=e=>Math.round(e*1e6)/1e6;function c(e,t,n,r,i){let a=s(Math.max(e.input-e.cache,0)/1e6*t.input*n),o=s(e.cache/1e6*(t.cache??0)*n),c=s(e.output/1e6*t.output*r),l=s(a+o+c);return{usage:e,rates:t,inputMultiplier:n,outputMultiplier:r,inputUsd:a,cacheUsd:o,outputUsd:c,reasoningUsd:0,totalUsd:l,totalBrl:i===null?null:s(l*i)}}function l(e,t){if(t===`standard`)return{input:e.input_per_million_usd,cache:e.cached_input_per_million_usd,output:e.output_per_million_usd};let n=e.priority_input_per_million_usd,r=e.priority_output_per_million_usd;return n==null||r==null?null:{input:n,cache:e.priority_cached_input_per_million_usd??null,output:r}}function u(e,t,n){let r=l(e,t);return r===null?null:c(o,r,1,1,n)}function d(e,t){return e.long_context_threshold_tokens===null?null:c({input:e.long_context_threshold_tokens+5e4,cache:o.cache,output:o.output,reasoning:o.reasoning},l(e,`standard`),e.long_context_input_multiplier,e.long_context_output_multiplier,t)}var f={"pt-BR":{eyebrow:`CONFIGURAÇÕES · TRANSPARÊNCIA`,title:`Como o custo é calculado`,intro:`Do menor grão — uma chamada LLM — até o total: veja quais tokens entram na conta e como modelo, esforço, contexto e velocidade mudam o resultado.`,back:`Voltar ao dashboard`,model:`Modelo usado nos exemplos`,currency:`Moeda`,unavailable:`Indisponível`,millionRate:`por 1 milhão de tokens`,rateTitle:`1. Comece pelas tarifas do modelo`,rateIntro:`O modelo escolhe a tabela de preços. Priority/Fast usa outra tabela quando o catálogo publica essas tarifas.`,standard:`Standard`,priority:`Priority / Fast`,input:`Input`,cache:`Cache`,output:`Output`,reasoning:`Reasoning`,ratio:`Priority ÷ Standard`,included:`Incluído no output (+0)`,noPublishedRate:`Sem tarifa publicada (custo adicional 0)`,conceptsTitle:`2. Entenda cada parte da chamada`,concepts:[[`Chamada LLM`,`É o menor grão do cálculo: uma requisição ao provedor, com um modelo e um tier de serviço.`],[`Input tokens`,`Tudo que entra no modelo: instruções, histórico, contexto, ferramentas e a mensagem atual.`],[`Cache tokens`,`São parte do input, não tokens extras. Primeiro subtraímos o cache do input e depois aplicamos sua tarifa própria.`],[`Output tokens`,`É o total produzido pelo modelo. O custo usa o output total informado pela telemetria.`],[`Reasoning tokens`,`São parte do output. O cálculo atual cobra o output uma vez e mantém reasoningUsd = 0, evitando cobrança dupla.`],[`Modelo e esforço`,`O modelo muda as tarifas. O esforço não tem multiplicador próprio, mas pode gerar mais reasoning, output ou ciclos e aumentar o custo indiretamente.`],[`Multiplicador de contexto`,`Acima do limite do modelo, o multiplicador de input vale também para cache; o multiplicador de output vale para todo o output.`],[`Multiplicador de velocidade`,`É a razão derivada entre o total Priority/Fast e o Standard. Serve para comparar; nunca é multiplicado de novo no total.`]],exampleTitle:`3. Exemplo simples, parcela por parcela`,exampleIntro:`Uma chamada com 100 mil tokens de input, dos quais 40 mil vieram do cache, e 20 mil tokens de output, dos quais 8 mil são reasoning.`,billableInput:`Input faturável`,operation:`Operação`,cost:`Custo`,total:`Total da chamada`,speedMultiplier:`Multiplicador de velocidade derivado`,longTitle:`4. Exemplo com contexto longo`,longIntro:`Para realmente ultrapassar o limite, o exemplo usa o threshold do modelo + 50 mil tokens de input. A conta abaixo continua no tier Standard.`,threshold:`Limite do modelo`,longInput:`Input do exemplo longo`,priorityLong:`Priority/Fast + contexto longo`,priorityLongNote:`Indisponível: sem uma combinação publicada no catálogo, o dashboard não inventa uma tarifa.`,finalNote:`Regra prática: escolha o modelo e o tier, separe input de cache, cobre o output total uma única vez e só então aplique câmbio. Mais esforço só aumenta o custo quando aumenta o uso registrado.`},"en-US":{eyebrow:`SETTINGS · TRANSPARENCY`,title:`How cost is calculated`,intro:`From the smallest grain — one LLM call — to the total: see which tokens enter the calculation and how model, effort, context, and speed affect it.`,back:`Back to dashboard`,model:`Model used in the examples`,currency:`Currency`,unavailable:`Unavailable`,millionRate:`per 1 million tokens`,rateTitle:`1. Start with the model rates`,rateIntro:`The model selects the price table. Priority/Fast uses a different table when the catalog publishes those rates.`,standard:`Standard`,priority:`Priority / Fast`,input:`Input`,cache:`Cache`,output:`Output`,reasoning:`Reasoning`,ratio:`Priority ÷ Standard`,included:`Included in output (+0)`,noPublishedRate:`No published rate (additional cost 0)`,conceptsTitle:`2. Understand each part of the call`,concepts:[[`LLM call`,`The smallest calculation grain: one provider request with one model and one service tier.`],[`Input tokens`,`Everything sent to the model: instructions, history, context, tools, and the current message.`],[`Cache tokens`,`They are part of input, not extra tokens. Cache is subtracted from input first, then its own rate is applied.`],[`Output tokens`,`Everything produced by the model. Cost uses the total output reported by telemetry.`],[`Reasoning tokens`,`They are part of output. Current math charges output once and keeps reasoningUsd = 0, preventing double billing.`],[`Model and effort`,`The model changes rates. Effort has no direct multiplier, but it can produce more reasoning, output, or cycles and indirectly raise cost.`],[`Context multiplier`,`Above the model threshold, the input multiplier also applies to cache; the output multiplier applies to all output.`],[`Speed multiplier`,`It is the derived ratio between Priority/Fast and Standard totals. It is only a comparison and is never multiplied into the total again.`]],exampleTitle:`3. A simple example, component by component`,exampleIntro:`One call with 100 thousand input tokens, including 40 thousand cache tokens, and 20 thousand output tokens, including 8 thousand reasoning tokens.`,billableInput:`Billable input`,operation:`Operation`,cost:`Cost`,total:`Call total`,speedMultiplier:`Derived speed multiplier`,longTitle:`4. Long-context example`,longIntro:`To actually exceed the limit, this example uses the model threshold + 50 thousand input tokens. The calculation remains on Standard tier.`,threshold:`Model threshold`,longInput:`Long-example input`,priorityLong:`Priority/Fast + long context`,priorityLongNote:`Unavailable: without a published combination in the catalog, the dashboard does not invent a rate.`,finalNote:`Rule of thumb: choose model and tier, separate input from cache, charge total output once, then apply FX. Higher effort only raises cost when it raises recorded usage.`}};function p(e,t,n,r){if(t===`BRL`&&n===null)return r;let i=t===`BRL`?e*n:e;return new Intl.NumberFormat(t===`BRL`?`pt-BR`:`en-US`,{style:`currency`,currency:t,minimumFractionDigits:2,maximumFractionDigits:6}).format(i)}function m(e,t,n,r,i){return e==null?i:p(e,t,n,r)}function h(e,t){return new Intl.NumberFormat(t).format(e)}function g({example:e,currency:t,fxRate:n,locale:r,labels:a}){let o=a.unavailable,s=Math.max(e.usage.input-e.usage.cache,0),c=e.inputMultiplier===1?``:` × ${e.inputMultiplier}`,l=e.outputMultiplier===1?``:` × ${e.outputMultiplier}`,u=e.rates.cache??0,d=[{label:a.billableInput,operation:`${h(e.usage.input,r)} − ${h(e.usage.cache,r)} = ${h(s,r)} tokens`,cost:null},{label:a.input,operation:`${h(s,r)} ÷ 1M × ${m(e.rates.input,t,n,o,a.noPublishedRate)}${c}`,cost:e.inputUsd},{label:a.cache,operation:`${h(e.usage.cache,r)} ÷ 1M × ${m(u,t,n,o,a.noPublishedRate)}${c}`,cost:e.cacheUsd},{label:a.output,operation:`${h(e.usage.output,r)} ÷ 1M × ${m(e.rates.output,t,n,o,a.noPublishedRate)}${l}`,cost:e.outputUsd},{label:a.reasoning,operation:`${h(e.usage.reasoning,r)} tokens ⊂ ${a.output} → +0`,cost:e.reasoningUsd}];return(0,i.jsxs)(`div`,{className:`cost-guide-calculation`,children:[(0,i.jsxs)(`div`,{className:`cost-guide-calculation-head`,"aria-hidden":`true`,children:[(0,i.jsx)(`span`,{}),(0,i.jsx)(`span`,{children:a.operation}),(0,i.jsx)(`span`,{children:a.cost})]}),d.map(e=>(0,i.jsxs)(`div`,{className:`cost-guide-calculation-line`,children:[(0,i.jsx)(`strong`,{children:e.label}),(0,i.jsx)(`code`,{children:e.operation}),(0,i.jsx)(`span`,{children:e.cost===null?`—`:p(e.cost,t,n,o)})]},e.label)),(0,i.jsxs)(`div`,{className:`cost-guide-calculation-total`,children:[(0,i.jsx)(`strong`,{children:a.total}),(0,i.jsx)(`span`,{children:p(e.totalUsd,t,n,o)})]})]})}function _({catalog:e,fxRate:t,locale:n,onClose:o}){let s=f[n],[c,l]=(0,r.useState)(e.models[0]?.id??``),[p,_]=(0,r.useState)(`USD`),v=(0,r.useMemo)(()=>e.models.find(e=>e.id===c)??e.models[0]??null,[e.models,c]);if(v===null)return(0,i.jsxs)(`main`,{className:`cost-guide`,children:[(0,i.jsxs)(`button`,{onClick:o,type:`button`,children:[`← `,s.back]}),(0,i.jsx)(`h1`,{children:s.title}),(0,i.jsx)(a,{locale:n}),(0,i.jsx)(`p`,{children:s.unavailable})]});let y=t?.rate??null,b=u(v,`standard`,y),x=u(v,`priority`,y),S=d(v,y),C=x!==null&&b.totalUsd>0?x.totalUsd/b.totalUsd:null,w=[{label:s.input,standard:v.input_per_million_usd,priority:v.priority_input_per_million_usd},{label:s.cache,standard:v.cached_input_per_million_usd,priority:v.priority_cached_input_per_million_usd},{label:s.output,standard:v.output_per_million_usd,priority:v.priority_output_per_million_usd}];return(0,i.jsxs)(`main`,{className:`cost-guide`,children:[(0,i.jsxs)(`header`,{children:[(0,i.jsxs)(`div`,{children:[(0,i.jsx)(`small`,{children:s.eyebrow}),(0,i.jsx)(`h1`,{children:s.title}),(0,i.jsx)(`p`,{children:s.intro})]}),(0,i.jsxs)(`button`,{onClick:o,type:`button`,children:[`← `,s.back]})]}),(0,i.jsx)(a,{locale:n}),(0,i.jsxs)(`section`,{className:`cost-guide-controls`,"aria-label":s.model,children:[(0,i.jsxs)(`label`,{children:[s.model,(0,i.jsx)(`select`,{value:v.id,onChange:e=>l(e.target.value),children:e.models.map(e=>(0,i.jsx)(`option`,{value:e.id,children:e.id},e.id))})]}),(0,i.jsxs)(`label`,{children:[s.currency,(0,i.jsxs)(`select`,{value:p,onChange:e=>_(e.target.value),children:[(0,i.jsx)(`option`,{value:`USD`,children:`USD`}),(0,i.jsxs)(`option`,{value:`BRL`,children:[`BRL `,y===null?`(${s.unavailable})`:`(1 USD = ${y.toFixed(4)} BRL)`]})]})]})]}),(0,i.jsxs)(`section`,{className:`cost-guide-section`,children:[(0,i.jsxs)(`div`,{className:`cost-guide-section-heading`,children:[(0,i.jsx)(`h2`,{children:s.rateTitle}),(0,i.jsx)(`p`,{children:s.rateIntro})]}),(0,i.jsx)(`div`,{className:`cost-guide-table-wrap`,children:(0,i.jsxs)(`table`,{children:[(0,i.jsxs)(`caption`,{children:[v.id,` · `,s.millionRate]}),(0,i.jsx)(`thead`,{children:(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`col`}),(0,i.jsx)(`th`,{scope:`col`,children:s.standard}),(0,i.jsx)(`th`,{scope:`col`,children:s.priority}),(0,i.jsx)(`th`,{scope:`col`,children:s.ratio})]})}),(0,i.jsxs)(`tbody`,{children:[w.map(e=>(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`row`,children:e.label}),(0,i.jsx)(`td`,{children:m(e.standard,p,y,s.unavailable,s.noPublishedRate)}),(0,i.jsx)(`td`,{children:m(e.priority,p,y,s.unavailable,s.noPublishedRate)}),(0,i.jsx)(`td`,{children:e.standard!==null&&e.standard>0&&e.priority!==null&&e.priority!==void 0?`${(e.priority/e.standard).toFixed(2)}×`:s.unavailable})]},e.label)),(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`row`,children:s.reasoning}),(0,i.jsx)(`td`,{colSpan:3,children:s.included})]})]})]})})]}),(0,i.jsxs)(`section`,{className:`cost-guide-section`,children:[(0,i.jsx)(`div`,{className:`cost-guide-section-heading`,children:(0,i.jsx)(`h2`,{children:s.conceptsTitle})}),(0,i.jsx)(`div`,{className:`cost-guide-blocks`,children:s.concepts.map(([e,t])=>(0,i.jsxs)(`article`,{children:[(0,i.jsx)(`strong`,{children:e}),(0,i.jsx)(`p`,{children:t})]},e))})]}),(0,i.jsxs)(`section`,{className:`cost-guide-section`,children:[(0,i.jsxs)(`div`,{className:`cost-guide-section-heading`,children:[(0,i.jsx)(`h2`,{children:s.exampleTitle}),(0,i.jsx)(`p`,{children:s.exampleIntro})]}),(0,i.jsxs)(`div`,{className:`cost-guide-example-grid`,children:[(0,i.jsxs)(`article`,{className:`cost-guide-example-card`,children:[(0,i.jsx)(`h3`,{children:s.standard}),(0,i.jsx)(g,{example:b,currency:p,fxRate:y,locale:n,labels:s})]}),(0,i.jsxs)(`article`,{className:`cost-guide-example-card`,children:[(0,i.jsx)(`h3`,{children:s.priority}),x===null?(0,i.jsx)(`p`,{className:`cost-guide-unavailable`,children:s.unavailable}):(0,i.jsx)(g,{example:x,currency:p,fxRate:y,locale:n,labels:s})]})]}),(0,i.jsxs)(`div`,{className:`cost-guide-speed`,children:[(0,i.jsx)(`span`,{children:s.speedMultiplier}),(0,i.jsx)(`strong`,{children:C===null?s.unavailable:`${C.toFixed(2)}×`}),(0,i.jsxs)(`code`,{children:[s.priority,` `,s.total,` ÷ `,s.standard,` `,s.total]})]})]}),(0,i.jsxs)(`section`,{className:`cost-guide-section`,children:[(0,i.jsxs)(`div`,{className:`cost-guide-section-heading`,children:[(0,i.jsx)(`h2`,{children:s.longTitle}),(0,i.jsx)(`p`,{children:s.longIntro})]}),(0,i.jsxs)(`div`,{className:`cost-guide-context-summary`,children:[(0,i.jsxs)(`span`,{children:[s.threshold,`:`,` `,(0,i.jsx)(`strong`,{children:v.long_context_threshold_tokens===null?s.unavailable:h(v.long_context_threshold_tokens,n)})]}),(0,i.jsxs)(`span`,{children:[s.longInput,`:`,` `,(0,i.jsx)(`strong`,{children:S===null?s.unavailable:h(S.usage.input,n)})]}),(0,i.jsxs)(`span`,{children:[`Input/cache: `,(0,i.jsxs)(`strong`,{children:[v.long_context_input_multiplier,`×`]})]}),(0,i.jsxs)(`span`,{children:[`Output: `,(0,i.jsxs)(`strong`,{children:[v.long_context_output_multiplier,`×`]})]})]}),S===null?(0,i.jsx)(`p`,{className:`cost-guide-unavailable`,children:s.unavailable}):(0,i.jsx)(g,{example:S,currency:p,fxRate:y,locale:n,labels:s}),(0,i.jsxs)(`div`,{className:`cost-guide-unavailable-combination`,children:[(0,i.jsxs)(`strong`,{children:[s.priorityLong,`: `,s.unavailable]}),(0,i.jsx)(`p`,{children:s.priorityLongNote})]})]}),(0,i.jsx)(`aside`,{className:`cost-guide-final-note`,children:s.finalNote})]})}export{_ as CostCalculationGuidePage};

package/templates/.agents/dashboard/apps/frontend/dist/assets/{DashboardHelpDialog-tg6j_0De.js → DashboardHelpDialog-DnxpHJSo.js}

@@ -1,4 +1,4 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{t as r}from"./dashboard-localization-CqicG5jJ.js";var i=`# Primeiros passos
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-YfoKMzCQ.js";import{t as r}from"./dashboard-localization-BVBhiAAS.js";var i=`# Primeiros passos
 
 1. Leia \`.agents/config/project.yaml\` e \`.agents/rules/core.md\`.
 2. Consulte \`.agents/records/lifecycle/\` para descobrir o estado atual pelos manifests canônicos.
@@ -228,7 +228,7 @@ ou recomeçar os workers. Veja [recuperação](16-lifecycle-e-reconciliacao.md).
 
 Antes de editar produto, execute \`zaip task workspace TASK-ID --run RUN-ID\` e confirme o modo e a posse. O hook usa a raiz Git comum para validar a Task/Run entre chats; registros de lifecycle continuam graváveis para bootstrap e fechamento. \`run finish\` tenta limpar automaticamente somente worktree isolado da Task terminal. Se bloqueado, use \`zaip task workspace TASK-ID --run RUN-ID --close\` depois de resolver o motivo sem apagar trabalho alheio.
 
-Para worktree isolado, o fechamento exige branch concluída integrada ou Task bloqueada, inventaria ignorados, cria bundle e snapshot verificados em \`.local/backup-branchs\` e \`.local/backup-worktrees\`, testa restauração e só então remove checkout/branch. Caches ignorados conhecidos são inventariados como descartáveis; ignorados desconhecidos bloqueiam. No checkout compartilhado, diff de produto misturado bloqueia limpeza automática até atribuição. O backup local é consulta recuperável e permanece fora do Git; limpeza posterior é manual.
+Para worktree isolado, o fechamento exige branch concluída integrada ou Task bloqueada, inventaria ignorados, cria bundle e snapshot verificados em \`.agents/private/state/backup-branchs\` e \`.agents/private/state/backup-worktrees\`, testa restauração e só então remove checkout/branch. Caches ignorados conhecidos são inventariados como descartáveis; ignorados desconhecidos bloqueiam. No checkout compartilhado, diff de produto misturado bloqueia limpeza automática até atribuição. O backup local é consulta recuperável e permanece fora do Git; limpeza posterior é manual.
 `,u=`# Revisao e validacao
 
 1. Revise Requirements e criterios de aceite.
@@ -1004,7 +1004,7 @@ uma autorização humana apenas no texto não substitui o contrato capturado.
 
 No fluxo nativo atual, editar produto exige posse central de escrita: \`zaip task workspace TASK-ID --run RUN-ID\`. A posse usa a raiz Git comum entre chats e worktrees e valida o dono e a Run; indisponibilidade bloqueia edição. Registros canônicos de lifecycle têm bootstrap próprio. Mensagens entre chats coordenam, mas não substituem Task, Run e claim. Alterações de produto sem proveniência única no checkout compartilhado bloqueiam transferência e limpeza automática até reconciliação.
 
-Para checkout isolado terminal, \`zaip task workspace TASK-ID --run RUN-ID --close\` inventaria arquivos e ignorados, exige integração se a Task concluiu, cria e testa backup em \`.local/backup-branchs\` e \`.local/backup-worktrees\` e só então remove worktree e branch. Ignorados desconhecidos ou backup não recuperável bloqueiam. \`.local\` fica fora do Git; o usuário limpa seus backups manualmente depois de conferi-los.
+Para checkout isolado terminal, \`zaip task workspace TASK-ID --run RUN-ID --close\` inventaria arquivos e ignorados, exige integração se a Task concluiu, cria e testa backup em \`.agents/private/state/backup-branchs\` e \`.agents/private/state/backup-worktrees\` e só então remove worktree e branch. Ignorados desconhecidos ou backup não recuperável bloqueiam. \`.local\` fica fora do Git; o usuário limpa seus backups manualmente depois de conferi-los.
 
 ## Diagnóstico antecipado e respostas compactas
 
@@ -1155,7 +1155,7 @@ selecionar/salvar um perfil não migra silenciosamente estados já materializado
 ## Contagem determinística e recuperação
 
 O coordenador gerenciado reserva a operação **antes** de chamar o provider em
-\`.local/autonomous/recovery/<hash-da-task>/ledger.json\`. O diário é durável,
+\`.agents/private/state/autonomous/recovery/<hash-da-task>/ledger.json\`. O diário é durável,
 privado e vinculado à Task, com escrita exclusiva e transições idempotentes.
 Não é cache descartável nem deve ser removido para liberar uma nova tentativa.
 
@@ -1362,8 +1362,8 @@ O ratchet de cobertura nunca reduz o piso: 80% para lines, functions e statement
 
 ## Checkout nativo corrente
 
-A descrição acima de worktree por Task pertence ao runtime autônomo gerenciado legado. Para Task avulsa Codex-native, \`task workspace\` concede posse exclusiva no checkout compartilhado e não cria branch. PRD/SPEC serial segue o mesmo padrão. Frentes paralelas usam branch/worktree próprios só com plano \`independent_branches\`, concorrência ativa e dependências e escopos disjuntos. Validação isolada curta usa worktree detached em \`.local/worktrees/validation\` e o remove após verificar. O fechamento de frente isolada exige snapshot e bundle recuperáveis antes de eliminar checkout/branch; diffs compartilhados misturados param para atribuição.
-`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- permissões de escrita no repositório consumidor.\n\nGit, identidade de autor, repositório, commit inicial e configuração do GitHub\npodem ser preparados depois da instalação. O runtime exige Git e histórico local\nantes de iniciar entregas; essa exigência não bloqueia `init`.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager` (11.12.0 neste snapshot), com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Resumo e próximos passos\n\nA resposta final do assistente mantém a frase inicial com o comando, a linha\n“Resumo:”, bullets e exatamente uma pergunta no final. Siga o modelo obrigatório\nde `.agents/skills/zaip-skill-setup/SKILL.md`, inclusive quando a instalação começou\nantes de as skills estarem disponíveis. Não converta o resumo em parágrafos.\nA versão instalada usa o rótulo `vVERSÃO` com link para sua página no npm,\ncontagens reais de arquivos e resultados de SQLite e `doctor`. O link usa\n`https://www.npmjs.com/package/@zaip-ai/cli/v/<versão-instalada>`.\n\nQuando o GitHub ainda precisa de configuração, a última pergunta é:\n**Deseja ajuda para configurar seu repositório Git?**\nSe a configuração local já estiver identificada, a pergunta será:\n**Deseja ajuda para realizar a configuração inicial do ZAIP-AIOS?**\nConfiguração local não comprova autenticação remota.\n\nNo terminal, a pergunta é textual: o comando encerra normalmente. No chat,\nresponder “sim” encaminha à skill de GitHub ou de configuração do projeto.\nA skill apresenta o que pode configurar e coleta as escolhas antes de editar.\nConcluído o GitHub, oferece a configuração do projeto; concluído o projeto,\nencerra o onboarding. Uma recusa ou adiamento encerra a oferta sem insistência.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nO candidato local v4 mantém a seleção do principal em `manual` e configura\n`execution.runtime: codex_native` para PRD/SPEC e Tasks avulsas, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha o alvo v4 Sol/high → Sol/high → Astra/high e execução elegível no\nterceiro bloco. Schema e template v4 já adotam Codex-native como padrão;\nadapters, pacote real e host ainda devem ser qualificados. O Essencial nunca usa Astra\nautomático. Principal avulso preserva a seleção manual; filhos seguem a\npolítica ZAIP verificada no host. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.local/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e os wrappers de skills dos clientes, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. No alvo v4, pedido de ação como “implemente” sem PRD/SPEC explícito vira Task avulsa; menção genérica ao macro não autoriza criá-lo. Em `draft`, PRD/SPEC só executa quando essa intenção for explícita; “crie e execute” usa a mesma sessão/turno Codex, mas Runs separadas de definição e delivery. Em `ready` executa; em estados ativos/falhos continua, retoma ou cria rework. “Desenvolva/melhore/aprimore” preserva a intenção: ação independente é Task, mero refinamento mantém draft. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo **somente em PRD/SPEC com DAG planejada**. Task avulsa é sequencial. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.\n\nCada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.local/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência. A v4\nacrescenta recuperação idempotente apenas da tentativa atual no fechamento ou\nno próximo evento Codex observável; não mantém agente rodando após o host parar.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
+A descrição acima de worktree por Task pertence ao runtime autônomo gerenciado legado. Para Task avulsa Codex-native, \`task workspace\` concede posse exclusiva no checkout compartilhado e não cria branch. PRD/SPEC serial segue o mesmo padrão. Frentes paralelas usam branch/worktree próprios só com plano \`independent_branches\`, concorrência ativa e dependências e escopos disjuntos. Validação isolada curta usa worktree detached em \`.agents/private/state/worktrees/validation\` e o remove após verificar. O fechamento de frente isolada exige snapshot e bundle recuperáveis antes de eliminar checkout/branch; diffs compartilhados misturados param para atribuição.
+`,C='# Como instalar e rodar o ZAIP-AIOS\n\nEste guia descreve o modelo de lifecycle V2 no layout V3. Durante a transição, layouts V1/V2 continuam disponíveis somente para leitura e migração; novos artefatos e seus manifests Git-native usam `.agents/records`.\n\n## Pré-requisitos\n\n- Node.js 22.16.0 ou superior, conforme o requisito do pacote, com `node:sqlite` disponível;\n- permissões de escrita no repositório consumidor.\n\nGit, identidade de autor, repositório, commit inicial e configuração do GitHub\npodem ser preparados depois da instalação. O runtime exige Git e histórico local\nantes de iniciar entregas; essa exigência não bloqueia `init`.\n\nO consumidor não precisa compilar o monorepo nem instalar pnpm para executar\no runtime distribuído. No checkout mantenedor, use o pnpm fixado em\n`packageManager`, com `corepack pnpm` quando disponível.\n\n## Instalação pública no projeto consumidor\n\nNa raiz do projeto-alvo:\n\n```bash\nnpx --yes @zaip-ai/cli@latest init --project-only --dry-run\nnpx --yes @zaip-ai/cli@latest init --project-only\nnode .agents/runtime/bin/zaip.mjs doctor --json\n```\n\nRevise o dry-run antes da instalação. O primeiro sucesso verificável é a saída\nde `doctor --json` com `"valid": true`; ela confirma layout, checksums e adapters\ndo projeto que recebeu a instalação. `@latest` seleciona a versão publicada,\nnão alterações ainda locais neste repositório. O binário público `zaip` é o\ninstalador; nos exemplos de lifecycle deste guia, `zaip ...` é uma abreviação\nde `node .agents/runtime/bin/zaip.mjs ...` no projeto consumidor. Use o caminho\nexplícito para evitar colisão entre os dois CLIs.\n\n### Resumo e próximos passos\n\nA resposta final do assistente mantém a frase inicial com o comando, a linha\n“Resumo:” e bullets. Só há pergunta quando falta uma escolha indispensável. Siga o modelo obrigatório\nde `.agents/skills/zaip-skill-setup/SKILL.md`, inclusive quando a instalação começou\nantes de as skills estarem disponíveis. Não converta o resumo em parágrafos.\nA versão instalada usa o rótulo `vVERSÃO` com link para sua página no npm,\ncontagens reais de arquivos e resultados de SQLite e `doctor`. O link usa\n`https://www.npmjs.com/package/@zaip-ai/cli/v/<versão-instalada>`.\n\nCodex é o padrão, sem pergunta “Codex ou Claude?”. O projeto novo recebe\n`clients.codex: true` e `clients.claude: false`. Para habilitar Claude por\npedido explícito, use `npx @zaip-ai/cli@latest init --claude`; a opção instala\nadapters e registra a preferência, não baixa o aplicativo Claude Code.\nUpdates preservam seleções existentes, inclusive Claude já habilitado.\n\nA instalação detecta o diretório e a configuração existente, verifica o template,\npreserva conteúdo do consumidor, instala as dependências ausentes conforme o perfil,\ngera adapters dos clientes habilitados e prepara o Dashboard SQLite. Depois verifica\n`doctor`, estado do Git/GitHub e integração Codex. Arquivos válidos, confiança\ndo projeto, aprovação de hooks e agentes carregados são provas distintas.\n`--project-only` mantém a configuração global do Codex fora da operação.\n\nO perfil é `full` em uma instalação nova; `--profile dev-lite|lite` seleciona\noutro e updates reutilizam o perfil salvo. O perfil não é uma pergunta interativa.\nO único prompt de confirmação da CLI é a reinstalação com `--force` sem\n`--yes`, em terminal interativo; sem TTY, a CLI exige `--yes`. Um pedido\nde update no chat usa o comando autorizado com `--force --yes --profile full`,\nsalvo restrição explícita, sem repetir a autorização.\nO próprio npm/npx pode pedir confirmação para baixar o pacote. O `--yes`\nantes de `@zaip-ai/cli` responde a essa confirmação; ele é separado do\n`--yes` após `init`, que confirma a reinstalação do ZAIP.\n\n### Perguntas no onboarding assistido\n\nNão há questionário obrigatório após instalar. A configuração do projeto só começa\nse fizer parte do pedido; Git/GitHub pendente é informado, sem oferta obrigatória.\nQuando a configuração estiver autorizada, descubra o que for verificável e reutilize\no contexto e os defaults. Pergunte apenas pelos dados materiais que ainda faltam:\n\n- Nome/finalidade do projeto ou fuso diferente, quando não estiverem resolvidos.\n- Stack e partes da aplicação necessárias, se não houver definição existente.\n- Preferência de acompanhamento de uso/custos, somente se precisar mudar ou decidir.\n- Destinos e branches de deploy pertinentes, se não estiverem definidos.\n- Em setup GitHub solicitado, identidade/conta/alvo que a descoberta não consiga\n  resolver com segurança; não peça credenciais no chat.\n\nAgrupe até cinco dúvidas indispensáveis por turno. Não pergunte por cliente,\nperfil ou escolhas já resolvidas. A aprovação de hooks pendentes é uma ação na UI\ndo Codex, informada uma vez, não uma pergunta de seleção nem uma aprovação textual.\nProvisionamento externo com custo, como beta hospedada Supabase, exige a autorização\nprópria dessa operação e não integra a instalação padrão. Configuração local não\ncomprova autenticação remota. Ao concluir, encerre sem CTA obrigatório; recusa ou\nadiamento encerra a etapa sem insistência.\n\n### Manuais e seleção de modelos\n\nAntes de usar os comandos de desenvolvimento abaixo, consulte os manuais instalados\nem `.agents/README.md` e `.agents/README-ENG.md` e o [índice local](../INDEX.md).\nO instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite`\ne `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade\nde uma tarefa nem ativam um modelo mais caro.\n\nO template atual preserva a seleção do principal no host e configura\n`model_orchestration.mode: auto` com `automatic_sources: [spec, prd]`,\n`execution.runtime: codex_native` para PRD/SPEC e Tasks avulsas, com\n`autonomy: { version: 1, preset: balanced }`. São controles diferentes:\ninstalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)\nexplica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)\ndetalha Sol/high → Sol/high → Astra/high e execução elegível no\nterceiro bloco. Schema e template adotam Codex-native como padrão;\nadapters, pacote real e host ainda devem ser qualificados. O Essencial nunca usa Astra\nautomático. Principal avulso preserva a seleção manual; filhos seguem a\npolítica ZAIP verificada no host. Projetos e estados legados\nnão recebem migração silenciosa de quotas.\n\n## Construir o CLI\n\nSomente no repositório-fonte, para manutenção do framework:\n\n```bash\ncorepack pnpm install --frozen-lockfile\ncorepack pnpm build\nnode packages/cli/dist/index.js version\n```\n\nNesse checkout compilado, use `node packages/cli/dist/index.js ...` para os\ncomandos de lifecycle. Em `--workspace`, informe o destino autorizado; não\nconfunda a raiz fonte com o projeto consumidor.\n\n## Setup pelo CLI de lifecycle\n\nFaça primeiro um dry-run e revise conflitos:\n\n```bash\nzaip setup --workspace /caminho/do/projeto --dry-run --json\nzaip setup --workspace /caminho/do/projeto\nzaip doctor --workspace /caminho/do/projeto\n```\n\nO setup V2 cria ou valida:\n\n```text\n.agents/config/{project.yaml,framework.lock.yaml}\n.agents/rules/{core,workflow,architecture,security,context}.md\n.agents/requirements/{work-lifecycle,execution-engine,cost-observability,kanban-dashboard,context-engine,software-architecture}.md\n.agents/skills/\n.agents/records/{prds,specs,changes,tasks,executions,runs}/\n.agents/records/lifecycle/\n.agents/private/state/claims/                 # claims idempotentes do lifecycle; não é histórico canônico\n```\n\nO runtime `.agents/runtime` usa a `.agents/` da raiz como fonte canônica das Rules, dos seis\nRequirements de área e das skills. Em uma instalação nova, o setup cria config e os seis diretórios\nvazios de data, projeta somente os arquivos portáveis do framework e registra a versão de origem em\n`source_release`. Histórico, Changes, Tasks, Runs e aliases específicos deste repositório nunca são\ncopiados para o projeto consumidor.\n\nO setup identifica a propriedade pelo `framework.lock.yaml`: Rules presentes no lock pertencem ao\nframework; as demais são locais ao projeto e são preservadas em instalações e upgrades. Conflitos\nde ID ou contradições bloqueiam a operação; não existe override silencioso.\n\nTambém gera adapters mínimos, como `AGENTS.md` e os wrappers de skills dos clientes, sem sobrescrever conteúdo do usuário silenciosamente.\n\n## Migrar estado V1\n\n```bash\nzaip migrate plan --workspace /caminho/do/projeto --json\nzaip migrate plan --workspace /caminho/do/projeto --verbose --json\nzaip migrate apply --workspace /caminho/do/projeto --plan-hash HASH\nzaip migrate status --workspace /caminho/do/projeto\n```\n\nPor padrão, `plan` retorna somente fingerprint, contagens, findings e hash. `--verbose` acrescenta metadados e paths das operações, nunca payload base64. `apply` exige o hash revisado; uma reaplicação/retomada pode selecionar explicitamente `--migration ID`.\n\nA migração deve ser idempotente. Até ser aplicada e verificada, raízes V1 permanecem legado somente leitura. Para desfazer uma migração suportada:\n\n```bash\nzaip migrate rollback --workspace /caminho/do/projeto --migration ID\n```\n\n## Escolher a entrada certa\n\nUse Task-first para uma alteração pontual e bem delimitada. Use SPEC quando o objetivo técnico exige várias Tasks, dependências ou execução autônoma longa. Use PRD quando é necessário traduzir objetivo de negócio, usuários, métricas e restrições em uma ou mais SPECs.\n\nPRD e SPEC são opcionais. O intake captura uma vez por turno observável;\ncontinuação reutiliza o foco válido e publicação puramente Git não cria\nlifecycle. Para pergunta, feedback ou análise read-only, `conversation start`\ne `conversation finish` registram uma interaction sem Task/Change artificial.\nCriar/refinar explicitamente PRD/SPEC `draft` pode persistir macro e PreparedPlan\nna própria interaction, sem delivery. Fora dessa exceção, alterações persistentes\nde código, documentação ou configuração exigem delivery, Task materializada e\nRun raiz ativa antes da escrita; caches/builds e projeções geradas seguem as\nisenções da Rule de workflow. Interaction read-only sem descendentes não exige\nexecutor nem finalizador.\n\nUma solicitação direta de ação entra em Execução; ela não passa artificialmente por Definição ou Planejamento. Uma Task independente que foi apenas preparada e ainda não começou fica em Pronto para executar. No quadro, Definição é exclusiva de PRDs em draft e Planejamento é exclusivo de SPECs em draft. O contrato completo está em [Lifecycle de trabalho](28-lifecycle-completo.md).\n\n## Task-first\n\nCrie o draft manual, prepare e execute explicitamente:\n\n```bash\nzaip task create --title "Ajuste pontual" --short-name ajuste-pontual --objective "Resultado esperado" --requirements REQ-ID --acceptance AC-ID --write-scopes src/**\nzaip task prepare TASK-ID\nzaip task execute TASK-ID\n```\n\nTask-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.\n\nTask-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as\ncolunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto\npara executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados\nantes da primeira mutação. Verificação e evidências sempre refletem registros reais.\n\nPara uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:\n\n```bash\nzaip plan build --draft ./task-plan-draft.json --output ./task-plan.json\nzaip plan validate --plan ./task-plan.json\nzaip task prepare TASK-ID --plan ./task-plan.json\nzaip task execute TASK-ID\n```\n\nO draft fornecido a `plan build` contém origem, Changes, Tasks, Execution, Requirements/AC e locks,\nmas não precisa calcular hash ou ordem topológica. Toda Task referenciada por `depends_on` precisa\nestar no mesmo plano. `plan validate` verifica o PreparedPlan completo sem materializá-lo.\n\n## SPEC opcional\n\n```bash\nzaip spec create --title "Objetivo técnico" --short-name objetivo-tecnico --objective "Resultado esperado"\nzaip spec prepare SPEC-ID --plan ./spec-plan.json\nzaip spec show SPEC-ID\nzaip spec execute SPEC-ID\n```\n\n`prepare` persiste IDs e DAG validada, sem criar Tasks. `execute` materializa a DAG de modo idempotente. A visão macro da SPEC agrega Tasks, Executions, Runs, evidências, retrabalho, tokens e custo.\n\n## PRD opcional\n\n```bash\nzaip prd create --title "Resultado de negócio" --short-name resultado-negocio --problem "Problema a resolver"\nzaip spec create --prd PRD-ID --title "Entrega técnica" --short-name entrega-tecnica --objective "Resultado técnico"\nzaip prd prepare PRD-ID --plan ./prd-plan.json\nzaip prd show PRD-ID\nzaip prd execute PRD-ID\n```\n\nÉ válido manter vários PRDs em rascunho, refinar alguns e executar somente os selecionados. `prepare`, `execute` e `deliver` bloqueiam PRD sem ao menos uma SPEC filha e qualquer Change do plano sem `spec_id`; o plano global inclui todas as Tasks e dependências selecionadas. `deliver` avalia somente as SPECs selecionadas no PreparedPlan do PRD, portanto outras SPECs filhas ainda em draft não bloqueiam a entrega.\n\nNa criação assistida, “me ajude a pensar” permanece Conversation. “Crie um PRD” faz até cinco perguntas críticas por turno e no máximo três turnos, depois persiste PRD/SPECs/PreparedPlan `draft` e registra decisões delegáveis da IA. Use uma SPEC por padrão; novas SPECs só representam capacidades independentes e paralelizáveis, sem arestas cross-SPEC. Blueprints compactos ficam visíveis antes do `ready`, mas Tasks/Changes/Execution só são materializadas quando o usuário pede “deixe/coloque em Pronto para Executar”, “finalize/conclua esse PRD” em `draft`, ou `execute`. A Run e o `creation_run_id` ficam vinculados ao macro; duração, tokens e custo só são agregados quando observados ou reconciliados e nunca são inventados quando indisponíveis.\n\n`execute` respeita Task, SPEC ou PRD conforme o menor grão nomeado. No alvo v4, pedido de ação como “implemente” sem PRD/SPEC explícito vira Task avulsa; menção genérica ao macro não autoriza criá-lo. Em `draft`, PRD/SPEC só executa quando essa intenção for explícita; “crie e execute” usa a mesma sessão/turno Codex, mas Runs separadas de definição e delivery. Em `ready` executa; em estados ativos/falhos continua, retoma ou cria rework. “Desenvolva/melhore/aprimore” preserva a intenção: ação independente é Task, mero refinamento mantém draft. PRD cancelado gera sucessor `draft` com tag `rework` e vínculo ao registro imutável.\n\n## Refinar sem executar\n\nNão existe comando `refine`. Enquanto PRD, SPEC ou Task estiver em `draft`, edite seu Markdown\ncanônico em `.agents/records`, incremente `revision` e atualize `updated_at`; em seguida use `show` e\nos validadores aplicáveis. Depois de `prepare`, não altere o plano silenciosamente: volte a um\ndraft por uma transição explicitamente suportada pela política da entidade ou cancele e crie um\nnovo draft. Isso preserva hash, auditoria e leitura humana.\n\nPara coleções grandes, use listagens compactas: `--status`, `--from`, `--to`, `--prd`, `--spec`, `--task`, `--limit` e `--after`. O padrão retorna no máximo 50 itens; `--all` é explícito.\n\n## Executar e acompanhar a DAG\n\nConsultas de acompanhamento:\n\n```bash\nzaip execution show EXEC-ID\nzaip task show TASK-ID\nzaip run show RUN-ID\nzaip run closure RUN-ID\n```\n\nA execução deve reutilizar a identidade real capturada do turno e seu alvo.\nNão crie um `run start --agent zaip-agent-finalizer` para simular a existência\nde Gui, nem interprete `run finish --status completed` como aprovação.\nO host captura spawn/terminal reais e persiste a decisão observada antes do\nStop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).\n\nTasks `planned` cujas dependências estejam concluídas podem rodar em paralelo **somente em PRD/SPEC com DAG planejada**. Task avulsa é sequencial. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.\n\nCada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.\n\n### Assurance e autonomia\n\nAtive a garantia tipada sem ativar execução por provider:\n\n```yaml\nexecution:\n  runtime: manual\nassurance:\n  version: 1\n  standard_depth: auto\n  require_final_commit: true\n```\n\nTask standalone `lite` exige no mínimo uma validação e uma Evidence — normalmente uma de cada, sem rejeitar provas extras legítimas. `standard` exige duas ou três validações conforme o `verification_scope` persistido e pelo menos uma Evidence consolidada; registros históricos sem esse sinal usam o fallback conservador de write scopes. `critical` exige três ou mais, revisão independente e os controles acionados pelos sinais de risco persistidos. SPEC/PRD exigem ainda três validações e três Evidences parentais, matriz completa, integração e review independente. Para o runtime autônomo, configuração, controles e estratégia econômica, veja [Assurance adaptativa e autonomia opt-in](19-assurance-e-autonomia.md).\n\n## Changes, decisões e evidências\n\nCada alteração possui `.agents/records/changes/YYYY/MM/CHG-.../change.md`, criado antes da primeira mutação. Ele registra:\n\n- plano e Requirement deltas;\n- implementação;\n- decisões humanas e da IA;\n- evidências por Acceptance Criterion;\n- evals e testes;\n- resultado final.\n\nCada teste, revisão, eval ou check executado também deve gerar um artefato reproduzível em\n`artifacts/tests/`, `artifacts/evals/` ou `artifacts/checks/`. O registro inclui ao menos\n`executed_at` com timezone, comando, status, Task, Run e Acceptance Criteria cobertos. Quando uma\nverificação não se aplica, registre `status: not_applicable` e a justificativa; ausência de registro\npermanece pendência. O dashboard contabiliza testes e considera uma etapa rastreada somente quando\nexiste timestamp de origem, sem substituir ausência pelo horário da consulta.\n\nQuando houver prova observável por AC, siga o contrato\n[canônico](../../skills/zaip-skill-change/references/observable-evidence.md).\n`validation observe` registra uma declaração sanitizada inline; não abre arquivo\nde entrada, não executa o procedimento e não cria Validation aprovada. Somente\numa observação `confirmed` e vinculada pode complementar Evidence já compatível.\n\nDecisões curtas ficam inline. Se uma decisão exigir ADR, salve-o em `decisions/` dentro da própria Change ou Execution e mantenha o resumo no Markdown principal.\n\n## Runs e custos\n\nUma Execution é `interaction` para conversa sem Task artificial ou `delivery` para trabalho materializado; esta última coordena a DAG quando existir. Run é a chamada raiz do `zaip-agent-orchestrator` e possui `parent_run_id: null`; Sub-Run é cada chamada de subagente e possui `parent_run_id`. Ambas usam o ledger `RUN-*`, fixam modelo e effort e podem conter várias Calls, ferramentas e segmentos de uso. `run_purpose` distingue orquestração, execução, revisão, auditoria e finalização. Calls permanecem internas e suas quantidades, tokens e custos aparecem agregados na Run/Sub-Run.\n\nOperação oferece Trabalho (Kanban) e Trabalho (Lista), ambas com os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista mostra status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura. Operação e Monitor de Custos apresentam Runs e Sub-Runs separadamente. Cada Execution agrega contagens de Runs, Sub-Runs, finalizadores, Tasks finalizadas e Calls conhecidas sem dupla contagem; telemetria incompleta aparece como parcial. Cada segmento de uso é atribuído uma única vez; correções de duplicidade usam supersessão sem apagar o histórico.\n\nA captura do Codex persiste primeiro um envelope sanitizado em\n`.agents/private/state/codex-telemetry-spool/v1/`, que permanece fora do Git. Depois do terminal da\ninvocação, a compactação produz um `InvocationSummary` e publica chunks e manifestos por\nano/mês/writer em `.agents/records/telemetry/`. Prompts, respostas, reasoning privado e segredos não\nentram nesses arquivos.\n\nQuando o Monitor de Custos recebe `from` e `to`, ele valida hashes e consulta os manifestos antes de\ncarregar somente os chunks compatíveis com o período e os filtros. Na ausência de summaries\naplicáveis, usa a projeção de Run existente sem promover a cobertura. O contrato completo, a\nsemântica de `complete|partial|unavailable` e o procedimento de recuperação estão em\n[Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\nO status técnico do Run (`completed`, `failed` ou `cancelled`) é separado do resultado da Task (`completed`, `blocked`, `failed` ou `cancelled`). Assim, um Run pode concluir tecnicamente e bloquear a Task porque um gate não passou. `execution` começa quando uma tentativa explícita se inicia, mesmo sem diff; `changed_files` e `result` registram se houve mutação.\n\n```bash\nzaip run start --short-name exemplo --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID\nzaip run usage RUN-ID --input-tokens N --output-tokens N\nzaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts\nzaip run closure RUN-ID\nzaip run show RUN-ID\nzaip run list --phase execution --task TASK-ID --limit 50\nzaip run aggregate --prd PRD-ID --from 2026-07-01 --to 2026-07-31\n```\n\n`run-v2` permanece alias compatível. `run list` retorna resumos compactos e paginados; combine\n`--phase`, `--entrypoint`, `--work-type`, `--conversation`, `--execution`, `--change`, `--task`,\n`--spec`, `--prd`, período e paginação. `run aggregate` usa os mesmos filtros para totalizar uso,\ncusto e cobertura sem dupla contagem. Valores ausentes permanecem nulos; dashboards mostram\ncobertura para impedir que custo desconhecido pareça custo zero.\n\nReconciliação global não roda ao abrir o dashboard, a cada turno ou em intervalo. Ela só é executada\nquando uma pessoa confirma o popup **Reconciliar** ou chama explicitamente\n`zaip run reconcile --open`. O reconciliador usa fatos locais: pode concluir uma Task com evento\nterminal exato; marca Run órfão depois da tolerância como falha técnica; transforma ausência de gates\nem bloqueio; e nunca infere cancelamento ou sucesso sem evidência. A v4\nacrescenta recuperação idempotente apenas da tentativa atual no fechamento ou\nno próximo evento Codex observável; não mantém agente rodando após o host parar.\n\n## Organizar frontend, backend e site\n\nCrie somente as superfícies usadas pelo projeto, mas preserve seus papéis:\n\n```text\napps/frontend/       # UI do produto\napps/backend/        # APIs e workers\napps/site/           # landing page e site público independente\nmodules/<area>/      # capacidades de negócio\npackages/<library>/  # bibliotecas técnicas\ntests/e2e/           # jornadas entre aplicações\n```\n\nA dependência aponta de `apps` para `modules` e destes para `packages`. O site público não importa\no dashboard, não lê `.agents` e não acessa implementação privada do backend.\n\nO dashboard ZAIP é outra fronteira, em `.agents/dashboard`. Ele possui somente\n`apps/frontend`; o servidor loopback fica em `packages/local-runtime`, acompanhado dos módulos\n`operations`, `cost-monitor` e `traceability`, demais packages próprios e `tests/e2e`. Ele lê\nos manifests canônicos em `.agents/records/lifecycle` e abre os demais records apenas por ID. A única\nreparação global iniciada pela UI ocorre após confirmação explícita no popup Reconciliar e usa o\ncomando canônico de reconciliação; não deve ser movido para o `apps/frontend` do produto\nnem publicado como `apps/site`.\n\nNo repositório-fonte do ZAIP, o gate de tamanho é executado isoladamente com:\n\n```bash\nnode scripts/validate-source-size.mjs\n```\n\nArquivos com 401–800 linhas geram warning; arquivos com 801 ou mais geram erro. Código gerado,\n`dist`, vendor, `node_modules`, `.agents/records` e lockfiles são ignorados. Exceções temporárias\nexistem apenas para legado não-dashboard, não podem crescer e precisam declarar responsável,\nmotivo e expiração.\n\n## Contrato CLI e taxonomia publicados\n\nO lifecycle observável avança em uma única direção: `conversation → planning → execution`. Task,\nSPEC e PRD são entrypoints distintos; Change narra a mutação, Execution coordena a DAG e Run mede\numa tentativa. O manifesto público do CLI cobre estas áreas e ações:\n\n```text\nzaip setup; zaip doctor\nzaip adapters build|check\nzaip context inventory|build|inspect\nzaip manifest rebuild|refresh|show|reconcile\nzaip verify --changed --risk lite|standard|critical\nzaip architecture validate; zaip cqrs validate; zaip modules validate; zaip profile validate\nzaip eval run\nzaip qa init|plan|run|next|record|status|resume|report\nzaip migrate plan|apply|status|rollback\nzaip plan build|validate|normalize\nzaip prd create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip spec create|list|show|prepare|ready|execute|activate|deliver|block|fail|cancel\nzaip change list|show|start|resume|block|verify|complete|fail|cancel\nzaip task create|list|next|show|prepare|execute|start|resume|rework|block|verify|complete|fail|cancel\nzaip execution list|show|start|resume|pause|block|verify|complete|fail|cancel\nzaip conversation start|finish\nzaip subagent capture\nzaip run start|list|aggregate|usage|finish|closure|reconcile|show\nzaip decision list|show|record\nzaip generate; zaip guard diff; zaip ui; zaip version\n```\n\n`pnpm test:contract` impede drift entre este guia, o manifesto de comandos, versões de packages,\nruntime distribuído e o gate de tamanho. `pnpm test:e2e` executa primeiro esse contrato e depois o\nE2E do dashboard.\n\n## Validação\n\nPara testar o próprio ZAIP-AIOS em um repositório destinado explicitamente a testes,\nuse a skill `zaip-skill-qa` e seu protocolo de host. `zaip qa init` registra o\nlaboratório; `plan`, `run`, `next` e `record` conduzem a execução com evidências,\nenquanto `status`, `resume` e `report` permitem acompanhar e retomar. Esse fluxo\nnão publica, não instala em consumidores reais e não altera infraestrutura.\nUma saída bem-sucedida de consulta não representa aprovação completa dos cenários.\n\n```bash\nzaip adapters check\nzaip context inventory\nzaip architecture validate\nzaip modules validate\nzaip profile validate\nzaip cqrs validate\nzaip eval run\n```\n\n`modules validate` verifica fronteiras entre `apps`, `modules` e `packages`. `profile validate`\nverifica o contrato de stack declarado em `.agents/config/project.yaml`. CQRS é obrigatório apenas quando o escopo contém casos de uso, estado ou separação de\ncommands/queries.\n\nNo repositório-fonte, rode também `pnpm validate:skills` e `pnpm test:encoding` após alterar Rules, Requirements, skills ou documentação.\n',w=`# Contrato de telemetria do Monitor de Custos
 
 Este guia descreve o contrato e não declara cobertura, totais ou preços de um período como estado atual.
 
@@ -1907,6 +1907,29 @@ Registro local de consulta em 15 de julho de 2026. Valores operacionais ficam no
 6. Preserve modelo, tier e effort efetivos como indisponíveis quando não forem retornados por fonte observada; defaults de configuração não os substituem.
 `,k=`# Qualidade e qualificação de release
 
+## Reuso parcial e lint antecipado
+
+O perfil essencial inclui o lint raiz e o lint do CLI público antes dos contratos
+de workflow e builds caros: são 21 gates obrigatórios. O perfil estendido conserva
+seus testes adicionais e executa esse lint público uma única vez. Uma falha de lint
+interrompe a preparação antes dos testes de paridade do pacote.
+
+No rapid, um grupo aprovado não precisa ser marcado como falho só porque outro
+grupo falhou depois. Sua aprovação é consolidada somente após revalidar candidato,
+entradas de política, ferramentas e instalação. A execução completa permanece
+reprovada e o grupo realmente falho mantém seu registro de falha. Na retomada,
+somente uma prova autenticada com identidade compatível recebe HIT. Mudança de
+código, dependências, política, ferramenta ou prova incompleta impede o reuso;
+grupos que exigem SHA exato continuam exigindo checkout limpo.
+
+O cenário automatizado A aprovado/B falho preservou A nas duas retomadas, evitando
+duas execuções repetidas de A. Esse resultado é de uma fixture com processos reais,
+não uma estimativa de horas ou tokens economizados em produção. A medição final de
+dependências é compartilhada pelos grupos pendentes; não se repete após cada grupo.
+Interrupção sem prova final não produz aprovação. Nunca edite o cache ou remova
+registros de falha para forçar um HIT; a qualificação assinada do TGZ permanece
+independente e obrigatória para publicação.
+
 ## Ajustes e publicação na v6.2
 
 Pedidos diretos de finalizar pendências, atualizar documentação e publicar uma
@@ -2297,6 +2320,14 @@ proteções de segredos, destruição, lifecycle, filhos restritos e energia do
 
 ## Ciclo corrente, limpeza e CI da main antes da Release
 
+No builder com opt-in versionado em \`.github/ci-validation.json\`, siga a
+[validação remota](../../skills/zaip-skill-release-qualification/references/remote-validation.md).
+Essa rota move os testes determinísticos para Actions na \`main\` existente,
+sem criar branches. O push autorizado inicia a qualificação; Release/npm exigem
+sucesso autenticado no SHA exato. Autorização humana de publicação, ciclo
+congelado, identidade exata, preservação de alterações, revisão e aceite continuam
+obrigatórios. Consumidores e recuperações históricas conservam suas próprias rotas.
+
 O manifesto versionado \`.agents/config/release-cycle.json\` identifica \`current_release\` e estado \`open\`/\`frozen\` (4.5 e 4.5.0 são normalizados). Drafts de PRD/SPEC futuros são permitidos; ready/execução, novas Tasks e código exigem o release corrente. Depois de conciliar Tasks atuais, prove \`main\`, branches, worktrees e registros antes do candidato. Branch/worktree isolados são fechados com backup local recuperável; checkout compartilhado com diff de proveniência mista bloqueia. A existência de \`main\` ou de um teste verde isolado não qualifica a release.
 
 Para congelar, use \`node scripts/release-cycle-gate.mjs freeze --repository ROOT --version VERSAO\`. A exceção da Task de coordenação exige risco crítico, alvo corrente, IDs explícitos \`--release-task TASK-ID --release-run RUN-ID\` e vínculos canônicos válidos. O manifesto frozen registra esses IDs. Há três contratos distintos:
@@ -2335,7 +2366,7 @@ evento observável do Codex
         │
         ▼
 spool local sanitizado e ignorado pelo Git
-.local/codex-telemetry-spool/v1/
+.agents/private/state/codex-telemetry-spool/v1/
         │
         ▼
 InvocationSummaryV1 por agent_invocation_id
@@ -2404,7 +2435,7 @@ catálogo, da seleção planejada ou do comportamento aparente.
 ### Chunks e manifestos
 
 Cada workspace recebe um \`writer-id\` aleatório persistido somente em
-\`.local/telemetry-writer-id.json\`. Isso separa autores e worktrees e reduz conflitos
+\`.agents/private/state/telemetry-writer-id.json\`. Isso separa autores e worktrees e reduz conflitos
 em um manifesto global compartilhado.
 
 Os summaries de cada mês são ordenados e escritos em chunk imutável endereçado pelo hash do
@@ -2518,7 +2549,7 @@ legados, substituição, truncamento, exclusão e concorrência exigem verifica
 de integridade e fallback completos. Redução mensurada, baseline equivalente,
 cobertura e carga concorrente precisam constar do benchmark; não declarar a
 matriz de performance aprovada apenas porque consultas focadas passaram.
-`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento separa o lifecycle existente do contrato aprovado para a v4.\nStatus persistido, Run, coluna do Kanban e reconciliação possuem\nresponsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Contrato aprovado para a v4 (a implementar e qualificar)\n\nAs regras a seguir são decisões de produto, **não** prova de que o runtime,\nhooks, Dashboard ou pacote npm atuais já as impõem. A qualificação deve\ncomparar código-fonte, artefato empacotado e uso real no Codex.\n\n1. Pergunta/análise read-only é Conversation, sem Task ou subagente. Pedido de\n   ação independente vira Task avulsa e usa subagentes nativos Codex, mesmo\n   quando o texto não menciona Task. Mencionar PRD/SPEC não os cria; crie macro\n   apenas por pedido explícito e mantenha `draft` até `ready` ou `execute`\n   explícito. Trabalho avulso crítico pode recomendar um macro, sem converter\n   automaticamente nem paralisar a ação já autorizada.\n2. “Crie e execute PRD/SPEC” pode acontecer no mesmo **turno do Codex**. A\n   definição usa sua Run `interaction`; a implementação usa outra Run\n   `delivery`, vinculada ao mesmo alvo e turno. Nunca reutilize ou reescreva a\n   Run de definição como se tivesse executado o produto. “Crie” isolado\n   termina em `draft`; `ready` não executa; `execute` não precisa passar\n   temporariamente pelo card Pronto para Executar.\n3. A Task avulsa é sequencial. Paralelismo produtivo só ocorre para Tasks de\n   PRD/SPEC em DAG planejada, com independência, escopos e recursos\n   compatíveis. Cada tentativa de Task termina `completed`, `blocked`,\n   `failed` ou `cancelled` antes de a Run responsável encerrar. Na falta de\n   prova/decisão, o fallback é `blocked`, com causa e condição de retomada;\n   nunca invente sucesso ou cancelamento. SPEC/PRD aguardam **todas** as\n   Tasks da DAG em estados terminais. Dependentes inviabilizadas por uma\n   Task bloqueada/falhada recebem terminal objetivo; somente depois disso e\n   dos gates parentais o macro pode ser entregue ou terminalizado com causa.\n4. Cada rodada horária, se o usuário tiver instalado a automação Codex,\n   reivindica somente **um** item superior `ready`: PRD, depois SPEC\n   independente, depois Task avulsa. Dentro da classe respeita a prioridade\n   manual do Kanban. Descendentes, ativos e terminais não são candidatos.\n   Lease e releitura do estado impedem seleção duplicada. Arquivos Git não\n   acordam o Codex; não prometa trabalho após o host parar.\n5. O preset `balanced` admite três replanejamentos reais por Task, com\n   diagnóstico Sol/high → Sol/high → Astra/high. Reserva antes do despacho,\n   evento observado, hipótese nova, teste discriminante e ledger imutável\n   evitam recontagem ou alegação de tentativa não executada. O controle\n   gerenciado existente não intercepta qualquer `spawn_agent` nativo; a v4\n   precisa implementar um preflight compatível com o host e bloquear quando\n   modelo, effort ou ferramenta requeridos não puderem ser assegurados.\n6. A reconciliação global do backlog continua manual. A tentativa **atual**\n   pode ser conciliada de modo idempotente ao fechamento ou no próximo evento\n   observável da mesma Task/turno; não há garantia de código rodando após o\n   Codex encerrar. Dashboard e scheduler apenas mostram/retomam fatos\n   canônicos, sem inferir aprovação.\n7. Depois do carregamento, cards e células **numéricas** do Dashboard exibem\n   `0` para ausência de medição; não exibem a palavra “Indisponível”. Mostram\n   também cobertura/tooltip “sem medição”, pois zero observado é diferente.\n   Durante carregamento exibem skeleton, não zero. Records, APIs, exports e\n   cálculos preservam `null`/cobertura parcial; zero visual nunca altera a\n   fonte canônica nem entra em somas como observação.\n\nO candidato local v4 usa `codex_native` no schema e no template npm. O modo\nnão inicia um processo autônomo separado; a efetividade da rota nativa ainda\ndepende da capacidade real da sessão Codex. Compatibilidade legada permanece\nseparada do caminho padrão novo. Isso não comprova publicação no npm.\n\n## Fronteiras nativas e prova de compatibilidade\n\nEsta é a matriz de aceite para o contrato acima. Um texto em `AGENTS.md`, Rule\nou skill instrui o agente, mas não altera sozinho o seletor de modelo do host,\nnão intercepta toda chamada e não cria um relógio. O caminho v4 usa as\nferramentas reais do Codex e valida capacidades disponíveis na sessão antes\nde prometer uma garantia.\n\n| Fronteira | Comportamento exigido para a v4 | Prova antes de anunciar suporte |\n| --- | --- | --- |\n| Intake | Separar Conversation de ação e correlacionar turno, intenção e alvo sem Task artificial. | Fixtures para pergunta, ação avulsa, criação `draft`, `ready`, execução e “crie e execute”; ausência de artefatos indevidos. |\n| Subagente nativo | Em toda Task avulsa, despachar um filho real e aguardar seu resultado; execução produtiva sequencial. Só uma DAG de PRD/SPEC autoriza filhos produtivos paralelos. | Captura de `spawn_agent`, identidade, modelo/effort solicitados e efetivamente observáveis, resultado terminal e nenhuma Task concorrente fora da DAG. |\n| Modelo e esforço | Consultar agente/perfil que o host disponibiliza. Validar a rota antes do spawn; preservar seleção manual do principal e distinguir intenção de configuração efetiva. | Teste com agente GPT-6 válido, modelo não disponível e fallback inesperado. Sem comprovação da configuração efetiva, manter telemetria `null` e bloquear a garantia automática. |\n| Replan | Reservar e registrar até três diagnósticos reais no Equilibrado, Sol/high, Sol/high, Astra/high; plano exige hipótese nova e teste que distingue a causa. | Ledger idempotente, casos de erro, interrupção, retry e capacidade ausente; não contar prompt, timeout ou reserva sem execução como diagnóstico concluído. |\n| Fechamento | Aguardar filhos e provas, executar Gui como último filho e aplicar sua decisão. Se Gui não iniciar, falhar ou a Run parar, o caminho confiável de fechamento registra `blocked` com motivo e retomada, sem inventar decisão de Gui. | Testes de Stop, interrupção e replay; nenhuma tentativa **formalmente encerrada** fica `executing`/`verifying`; recibo recuperável quando a escrita falha. |\n| Agenda | Instalar somente a pedido uma tarefa agendada nativa do desktop para um item superior `ready` por rodada, com lease e prioridade do Kanban. | Inspeção da automação realmente criada, duas rodadas sem duplicação e teste de worktree/local; sem app/máquina ativa, informar ausência de execução. |\n| Dados e UI | Reconciliar fontes canônicas e worktrees; mostrar skeleton durante carga e `0` visual nos campos numéricos sem medição, com cobertura explícita. | Comparar records → SQLite → API → cards/tabelas; `null` continua em API/export/cálculo, inclusive nos períodos Hoje/Ontem/Esta Semana. |\n| Distribuição | Builder e projeto novo/atualizado pelo npm instalam os mesmos adapters, Rules, skills e configuração suportada. | Testar TGZ exato em fixture limpa e atualização Windows/PowerShell, `doctor`, adaptadores, ciclo Codex e idempotência. |\n\nOs [subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents)\npermitem perfis próprios e herança de modelo/effort; a disponibilidade\nconcreta e o agente escolhido dependem da sessão. Os\n[hooks do Codex](https://learn.chatgpt.com/docs/hooks) cobrem muitas\nferramentas locais, mas admitem caminhos especializados fora dessa cobertura.\n`PreToolUse` pode impedir chamadas cobertas; `Stop` pode solicitar uma nova\ncontinuação, não provar que o trabalho terminou, nem impedir uma interrupção\nhumana. Por isso o hook é checkpoint e reparo observável, nunca substituto\nuniversal de estado canônico, Gui ou ferramenta de despacho. As\n[tarefas agendadas](https://learn.chatgpt.com/docs/automations) têm execução\nprópria do app; em projeto local dependem de computador ligado e app ativo.\nO agendamento não é instalado só porque os arquivos existem no Git.\n\nSe o processo for encerrado antes do Stop ou da escrita, nenhum componente\nlocal consegue garantir a transição **naquele instante**. A garantia honesta é\num evento durável recuperável e a conciliação na próxima execução observável;\naté lá, o estado pode continuar aberto e o Dashboard deve indicá-lo, não\ninventar um terminal. Esse limite do host não autoriza encerrar a Run com\n`executing` como se fosse sucesso.\n\nLacunas verificadas neste candidato: a CLI recusa `task block` direto sem decisão\nde Gui, mas `run finish` aplica `blocked` como fallback quando é realmente\nchamado sem essa decisão. Uma interrupção antes desse comando ainda pode deixar\na Task em `executing` até a retomada/reconciliação. A fila agendada agora\nreivindica no máximo um item por lease; a rota Sol/Sol/Astra não está provada\npara toda chamada nativa. São itens de implementação, não decisões humanas\npendentes. A documentação é aprovada quando descreve essas lacunas; o produto\nsó está pronto quando a matriz passa no Codex e no pacote instalado.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\nNo contrato atual, `implemente` sem alvo abre Conversation de planejamento; na v4, quando houver objetivo independente de ação, entra como Task avulsa. Em PRD/SPEC `draft`, só executa com intenção explícita de executar o macro; criar/refinar isoladamente mantém `draft`. Em `ready`, executar inicia; em `active|blocked|failed`, continua/retoma/rework conforme estado. `desenvolva|melhore|aprimore` com intenção explícita de ação independente também não é reduzido a planejamento só pelo verbo. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição após a decisão real. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. **Contrato-alvo v4:** finalizador ausente, incompleto ou falho produz `blocked` por um caminho confiável separado, nunca uma aprovação sintética. No candidato atual, a CLI ainda pode deixar a Task em `executing` porque rejeita bloqueio direto sem Gui; essa lacuna precisa de correção e teste.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nDepois de capturar a decisão real do finalizador, o orquestrador pode aplicar\no fechamento pela CLI. O trecho abaixo **não** funciona como atalho para\n`task block` ou `run finish` sem essa decisão já persistida:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes do último Gui, consulte o [preflight do guia 16](16-lifecycle-e-reconciliacao.md#diagnóstico-antecipado-e-respostas-compactas).\nEle separa autoridade para `completed`, descendentes ativos e prontidão de\ndespacho; não substitui decisão nem gates. Recuperação pós-publicação revalida\nrecibo, publicação e proprietário único; observação passiva elegível não é outro\nexecutor. Em `same_turn_handoff`, a telemetria física é atribuída uma única vez,\nconforme o [guia 27](27-telemetria-git-native.md). Saída compacta preserva o cálculo\ninterno e não comprova menor duração.\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim **formalmente persistido** da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração exige recuperação retomável; quando o evento de\ninterrupção for observado e a escrita funcionar, o alvo é `blocked`. Morte\nabrupta do processo pode deixar o estado pendente até o próximo evento\nobservável, como descrito acima. “Cancelar a Task” é decisão explícita e\nresulta em `cancelled` somente quando persistida.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks da DAG ficam terminais, o macro pode entrar em\n  Verificação quando todas concluíram; bloqueios/falhas e dependentes inviáveis\n  são fechados com causa antes de decidir o resultado parental.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence\n  próprios do pai. Um pai não é `delivered` se uma filha bloqueou/falhou.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação **global** ao abrir o dashboard, em cada turno ou em intervalo automático. O contrato-alvo v4 acrescenta conciliação **direcionada à tentativa atual** no fechamento/Stop observado ou no próximo evento Codex da mesma Task, nunca uma varredura global silenciosa.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A exceção de raiz avulsa direta\nautorizada pertence à compatibilidade do contrato atual; no padrão Codex-native\nda v4, a Task avulsa terá executor subagente nativo observado. Nenhum dos dois\ncaminhos dispensa Evidence, gates e decisão real de Gui.\n\n## Regra operacional de checkout e release\n\nBranch é uma linha de commits; worktree é outra pasta de checkout que pode apontar para uma branch. Task avulsa ou PRD/SPEC serial usa um único checkout e um escritor por Task/Run registrado na raiz Git comum. Assim, uma edição pequena não cria branch. Só frentes paralelas independentes, com concorrência ativa, dependências resolvidas e `write_scopes` disjuntos, recebem branch e worktree separados. Um teste isolado pode usar worktree detached temporário em `.local/worktrees/validation`.\n\nNo fim da Task isolada, integre trabalho concluído, inventarie arquivos e ignorados, faça bundle/snapshot verificáveis em `.local/backup-branchs` e `.local/backup-worktrees` e feche branch/worktree. Se a Task estiver bloqueada, preserve o trabalho no backup antes de liberar o checkout. A limpeza dos backups é manual. No checkout compartilhado, alterações de várias Tasks sem atribuição verificável bloqueiam fechamento automático.\n\nO ciclo em `.agents/config/release-cycle.json` admite drafts de PRD/SPEC futuros, mas execução só do release corrente. `freeze`, `audit` e `advance` exigem prova de SHA, estado canônico e branches/worktrees. Para release/crítico, checks locais fixos antecedem o push de `main`; CI remoto do mesmo SHA antecede a Release. A exceção de uma Task de coordenação de release exige identidade explícita no manifesto congelado, Run ativa no freeze, risco crítico, alvo corrente e escopos somente de release. Ela termina e integra seus records no candidato antes de `audit`; audit/advance conferem os records no SHA. Até a auditoria ficar verde, o release permanece pendente.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
+`,j='# Lifecycle de Conversations, Tasks, SPECs e PRDs\n\nEste documento separa o lifecycle existente do contrato aprovado para a v4.\nStatus persistido, Run, coluna do Kanban e reconciliação possuem\nresponsabilidades distintas e não devem ser inferidos uns dos outros.\n\n## Contrato aprovado para a v4 (a implementar e qualificar)\n\nAs regras a seguir são decisões de produto, **não** prova de que o runtime,\nhooks, Dashboard ou pacote npm atuais já as impõem. A qualificação deve\ncomparar código-fonte, artefato empacotado e uso real no Codex.\n\n1. Pergunta/análise read-only é Conversation, sem Task ou subagente. Pedido de\n   ação independente vira Task avulsa e usa subagentes nativos Codex, mesmo\n   quando o texto não menciona Task. Mencionar PRD/SPEC não os cria; crie macro\n   apenas por pedido explícito e mantenha `draft` até `ready` ou `execute`\n   explícito. Trabalho avulso crítico pode recomendar um macro, sem converter\n   automaticamente nem paralisar a ação já autorizada.\n2. “Crie e execute PRD/SPEC” pode acontecer no mesmo **turno do Codex**. A\n   definição usa sua Run `interaction`; a implementação usa outra Run\n   `delivery`, vinculada ao mesmo alvo e turno. Nunca reutilize ou reescreva a\n   Run de definição como se tivesse executado o produto. “Crie” isolado\n   termina em `draft`; `ready` não executa; `execute` não precisa passar\n   temporariamente pelo card Pronto para Executar.\n3. A Task avulsa é sequencial. Paralelismo produtivo só ocorre para Tasks de\n   PRD/SPEC em DAG planejada, com independência, escopos e recursos\n   compatíveis. Cada tentativa de Task termina `completed`, `blocked`,\n   `failed` ou `cancelled` antes de a Run responsável encerrar. Na falta de\n   prova/decisão, o fallback é `blocked`, com causa e condição de retomada;\n   nunca invente sucesso ou cancelamento. SPEC/PRD aguardam **todas** as\n   Tasks da DAG em estados terminais. Dependentes inviabilizadas por uma\n   Task bloqueada/falhada recebem terminal objetivo; somente depois disso e\n   dos gates parentais o macro pode ser entregue ou terminalizado com causa.\n4. Cada rodada horária, se o usuário tiver instalado a automação Codex,\n   reivindica somente **um** item superior `ready`: PRD, depois SPEC\n   independente, depois Task avulsa. Dentro da classe respeita a prioridade\n   manual do Kanban. Descendentes, ativos e terminais não são candidatos.\n   Lease e releitura do estado impedem seleção duplicada. Arquivos Git não\n   acordam o Codex; não prometa trabalho após o host parar.\n5. O preset `balanced` admite três replanejamentos reais por Task, com\n   diagnóstico Sol/high → Sol/high → Astra/high. Reserva antes do despacho,\n   evento observado, hipótese nova, teste discriminante e ledger imutável\n   evitam recontagem ou alegação de tentativa não executada. O controle\n   gerenciado existente não intercepta qualquer `spawn_agent` nativo; a v4\n   precisa implementar um preflight compatível com o host e bloquear quando\n   modelo, effort ou ferramenta requeridos não puderem ser assegurados.\n6. A reconciliação global do backlog continua manual. A tentativa **atual**\n   pode ser conciliada de modo idempotente ao fechamento ou no próximo evento\n   observável da mesma Task/turno; não há garantia de código rodando após o\n   Codex encerrar. Dashboard e scheduler apenas mostram/retomam fatos\n   canônicos, sem inferir aprovação.\n7. Depois do carregamento, cards e células **numéricas** do Dashboard exibem\n   `0` para ausência de medição; não exibem a palavra “Indisponível”. Mostram\n   também cobertura/tooltip “sem medição”, pois zero observado é diferente.\n   Durante carregamento exibem skeleton, não zero. Records, APIs, exports e\n   cálculos preservam `null`/cobertura parcial; zero visual nunca altera a\n   fonte canônica nem entra em somas como observação.\n\nO candidato local v4 usa `codex_native` no schema e no template npm. O modo\nnão inicia um processo autônomo separado; a efetividade da rota nativa ainda\ndepende da capacidade real da sessão Codex. Compatibilidade legada permanece\nseparada do caminho padrão novo. Isso não comprova publicação no npm.\n\n## Fronteiras nativas e prova de compatibilidade\n\nEsta é a matriz de aceite para o contrato acima. Um texto em `AGENTS.md`, Rule\nou skill instrui o agente, mas não altera sozinho o seletor de modelo do host,\nnão intercepta toda chamada e não cria um relógio. O caminho v4 usa as\nferramentas reais do Codex e valida capacidades disponíveis na sessão antes\nde prometer uma garantia.\n\n| Fronteira | Comportamento exigido para a v4 | Prova antes de anunciar suporte |\n| --- | --- | --- |\n| Intake | Separar Conversation de ação e correlacionar turno, intenção e alvo sem Task artificial. | Fixtures para pergunta, ação avulsa, criação `draft`, `ready`, execução e “crie e execute”; ausência de artefatos indevidos. |\n| Subagente nativo | Em toda Task avulsa, despachar um filho real e aguardar seu resultado; execução produtiva sequencial. Só uma DAG de PRD/SPEC autoriza filhos produtivos paralelos. | Captura de `spawn_agent`, identidade, modelo/effort solicitados e efetivamente observáveis, resultado terminal e nenhuma Task concorrente fora da DAG. |\n| Modelo e esforço | Consultar agente/perfil que o host disponibiliza. Validar a rota antes do spawn; preservar seleção manual do principal e distinguir intenção de configuração efetiva. | Teste com agente GPT-6 válido, modelo não disponível e fallback inesperado. Sem comprovação da configuração efetiva, manter telemetria `null` e bloquear a garantia automática. |\n| Replan | Reservar e registrar até três diagnósticos reais no Equilibrado, Sol/high, Sol/high, Astra/high; plano exige hipótese nova e teste que distingue a causa. | Ledger idempotente, casos de erro, interrupção, retry e capacidade ausente; não contar prompt, timeout ou reserva sem execução como diagnóstico concluído. |\n| Fechamento | Aguardar filhos e provas, executar Gui como último filho e aplicar sua decisão. Se Gui não iniciar, falhar ou a Run parar, o caminho confiável de fechamento registra `blocked` com motivo e retomada, sem inventar decisão de Gui. | Testes de Stop, interrupção e replay; nenhuma tentativa **formalmente encerrada** fica `executing`/`verifying`; recibo recuperável quando a escrita falha. |\n| Agenda | Instalar somente a pedido uma tarefa agendada nativa do desktop para um item superior `ready` por rodada, com lease e prioridade do Kanban. | Inspeção da automação realmente criada, duas rodadas sem duplicação e teste de worktree/local; sem app/máquina ativa, informar ausência de execução. |\n| Dados e UI | Reconciliar fontes canônicas e worktrees; mostrar skeleton durante carga e `0` visual nos campos numéricos sem medição, com cobertura explícita. | Comparar records → SQLite → API → cards/tabelas; `null` continua em API/export/cálculo, inclusive nos períodos Hoje/Ontem/Esta Semana. |\n| Distribuição | Builder e projeto novo/atualizado pelo npm instalam os mesmos adapters, Rules, skills e configuração suportada. | Testar TGZ exato em fixture limpa e atualização Windows/PowerShell, `doctor`, adaptadores, ciclo Codex e idempotência. |\n\nOs [subagentes do Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents)\npermitem perfis próprios e herança de modelo/effort; a disponibilidade\nconcreta e o agente escolhido dependem da sessão. Os\n[hooks do Codex](https://learn.chatgpt.com/docs/hooks) cobrem muitas\nferramentas locais, mas admitem caminhos especializados fora dessa cobertura.\n`PreToolUse` pode impedir chamadas cobertas; `Stop` pode solicitar uma nova\ncontinuação, não provar que o trabalho terminou, nem impedir uma interrupção\nhumana. Por isso o hook é checkpoint e reparo observável, nunca substituto\nuniversal de estado canônico, Gui ou ferramenta de despacho. As\n[tarefas agendadas](https://learn.chatgpt.com/docs/automations) têm execução\nprópria do app; em projeto local dependem de computador ligado e app ativo.\nO agendamento não é instalado só porque os arquivos existem no Git.\n\nSe o processo for encerrado antes do Stop ou da escrita, nenhum componente\nlocal consegue garantir a transição **naquele instante**. A garantia honesta é\num evento durável recuperável e a conciliação na próxima execução observável;\naté lá, o estado pode continuar aberto e o Dashboard deve indicá-lo, não\ninventar um terminal. Esse limite do host não autoriza encerrar a Run com\n`executing` como se fosse sucesso.\n\nLacunas verificadas neste candidato: a CLI recusa `task block` direto sem decisão\nde Gui, mas `run finish` aplica `blocked` como fallback quando é realmente\nchamado sem essa decisão. Uma interrupção antes desse comando ainda pode deixar\na Task em `executing` até a retomada/reconciliação. A fila agendada agora\nreivindica no máximo um item por lease; a rota Sol/Sol/Astra não está provada\npara toda chamada nativa. São itens de implementação, não decisões humanas\npendentes. A documentação é aprovada quando descreve essas lacunas; o produto\nsó está pronto quando a matriz passa no Codex e no pacote instalado.\n\n## Classificação de entrada\n\nAliases são resolvidos com alvo e status persistido, nunca por palavra isolada. `pronto`, `deixe/coloque em Pronto para Executar` e `ready-to-execute` resolvem para `ready`. `finalizar|concluir|finalize|conclude` em PRD/SPEC `draft|ready` lapidam e resolvem para `ready`; em trabalho ativo, “conclua a execução/finalize a implementação” continua Tasks e gates. Somente `entregar|deliver` após gates solicita entrega terminal.\n\nNo contrato atual, `implemente` sem alvo abre Conversation de planejamento; na v4, quando houver objetivo independente de ação, entra como Task avulsa. Em PRD/SPEC `draft`, só executa com intenção explícita de executar o macro; criar/refinar isoladamente mantém `draft`. Em `ready`, executar inicia; em `active|blocked|failed`, continua/retoma/rework conforme estado. `desenvolva|melhore|aprimore` com intenção explícita de ação independente também não é reduzido a planejamento só pelo verbo. PRD cancelado é imutável e recebe sucessor `draft` com tag `rework` e `rework_of_prd_id`.\n\n## Criação completa de PRD e SPEC\n\n“Me ajude a pensar” é Conversation. “Crie um PRD” revisa o prompt, faz até cinco perguntas críticas por turno durante no máximo três turnos e então persiste PRD `draft`, SPECs técnicas `draft` e PreparedPlan com blueprints de Tasks. Decisões delegáveis restantes são registradas como IA; autoridade externa/destrutiva, credenciais e riscos não delegáveis continuam bloqueantes.\n\nUse uma SPEC por padrão. Outra só existe quando pode ser implementada e verificada em paralelo contra contrato estável, sem depender de outra SPEC ou disputar write scopes. Dependências e ordem ficam entre Tasks da mesma SPEC.\n\nAntes de `ready`, blueprints aparecem apenas como lista compacta no PRD/SPEC; `prd create --plan` e `spec create --plan` validam o pacote antes da escrita, usam criação exclusiva por arquivo e rollback compensatório se uma etapa falhar, mas não prometem uma transação atômica multiarquivo contra interrupção abrupta. Não existem registros Task, Change ou Execution `delivery` nessa etapa. `prd create|rework|prepare` exige uma Run delegada da Bia (`zaip-agent-analyst`) e `spec create|rework|prepare` exige uma Run delegada do Rafa (`zaip-agent-builder`), sempre ativas e vinculadas ao turno raiz atual, com propósito `execution`. Em criação composta, `prd create --plan --run <bia-run> --spec-run <rafa-run>` exige duas Runs distintas sob o mesmo orquestrador: o PRD recebe a autoria da Bia e as SPECs recebem a autoria do Rafa. Replays históricos e identidades trocadas falham antes de escrever artefatos. Duração, tokens e custo são agregados quando observados ou reconciliados e permanecem `null` quando indisponíveis. `ready` materializa Tasks/Changes/Execution como `planned` em operação idempotente; `execute` inicia o menor grão nomeado.\n\n| Entrada | Quando usar | Cria Task? | Estado inicial visível |\n| --- | --- | --- | --- |\n| Conversation | Pergunta, feedback, status ou análise pontual read-only; cria Execution `interaction` | Não | Sem card |\n| Task avulsa executável | Pedido direto de alteração ou resultado independente | Sim | Execução antes da primeira mutação |\n| Task avulsa preparada | Pedido explícito de planejamento sem autorização de executar | Sim | Pronto para Executar |\n| SPEC | Entrega técnica com múltiplos blueprints ou DAG | Tasks em `ready|execute` | Planejamento enquanto `draft` |\n| PRD | Definição de produto organizada em SPECs independentes | Tasks em `ready|execute` | Definição enquanto `draft` |\n\nConversa de análise nunca altera código, documentação ou configuração. A criação ou o refinamento explícito de PRD/SPEC `draft` é a única exceção de definição: a Execution `interaction` pode persistir o macro e seu PreparedPlan sem Task, Change ou Execution `delivery`. Fora dessa exceção, qualquer mutação persistente intencional exige Task materializada e Run raiz de orquestração ativa antes da escrita.\n\nSão isentos apenas deploy/publicação Git sem mudança de produto, manifests e telemetria ZAIP gerados pelo lifecycle, metadados `.git`, caches, builds, testes e arquivos temporários descartáveis. Editar fontes ou documentação do ZAIP não é isento.\n\n## Colunas do Kanban\n\n| Coluna | Regra |\n| --- | --- |\n| Definição | Exclusiva de PRD `draft` |\n| Planejamento | Exclusiva de SPEC `draft` |\n| Pronto para Executar | PRD/SPEC `ready` e toda Task `planned` nunca iniciada ou tentada, avulsa ou vinculada a SPEC |\n| Execução | Task `executing`; SPEC/PRD `active` |\n| Verificação | Task `verifying` ou macro executando gates parentais |\n| Concluído | Task `completed` ou macro `delivered` |\n| Bloqueado | Resultado retomável com condição objetiva |\n| Falhado | Erro técnico impeditivo; exige rework |\n| Cancelado | Cancelamento humano explícito e imutável |\n\nActivity local nunca prevalece sobre um status final persistido. Uma invocação obsoleta não pode reviver Task concluída, bloqueada, falhada ou cancelada.\n\n## Trabalho, Execution, Run, Sub-Run e Call\n\nAs cinco camadas possuem responsabilidades diferentes:\n\n| Camada | Responsabilidade |\n| --- | --- |\n| Trabalho | Task, SPEC ou PRD que descreve o resultado e seu lifecycle |\n| Execution | `interaction` registra uma conversa; `delivery` coordena Task, Change e DAG quando aplicável |\n| Run | Chamada raiz do `zaip-agent-orchestrator`; possui `parent_run_id: null` |\n| Sub-Run | Chamada de subagente feita dentro da Run; possui `parent_run_id` |\n| Call | Invocação interna de modelo LLM; herda a configuração da Run/Sub-Run |\n\nRun e Sub-Run compartilham o mesmo ledger canônico `RUN-*`; a distinção é derivada de `parent_run_id`, sem entidade duplicada. `run_role` usa somente `intake`, `orchestrator` ou `subagent`; valores históricos `owner` e `contributor` são aceitos apenas na leitura e normalizados imediatamente. `run_purpose` informa se a chamada executa `orchestration`, `execution`, `review`, `audit` ou `finalization`.\n\nCada Run/Sub-Run fixa agente, modelo e effort até terminar. Mudança deliberada de agente, modelo, effort ou fase material abre outra chamada de agente; retry técnico preserva a configuração corrente. Calls podem ser várias dentro da mesma chamada de agente e não possuem lifecycle nem tela própria.\n\nQuando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais, falhas, cancelamentos, configuração efetiva, tokens e custo. Ausência de telemetria permanece `null`; nunca se presume zero e nunca se cria `CallProjection`.\n\n### Barreira do finalizador\n\nCada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.\n\nO finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição após a decisão real. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. **Contrato-alvo v4:** finalizador ausente, incompleto ou falho produz `blocked` por um caminho confiável separado, nunca uma aprovação sintética. No candidato atual, a CLI ainda pode deixar a Task em `executing` porque rejeita bloqueio direto sem Gui; essa lacuna precisa de correção e teste.\n\nNo modo nativo do Codex, a orquestração materializa essa etapa como um envelope de delegação com `purpose: finalization`, `agent_id: agent-finalizer`, escopo de escrita vazio e chave de idempotência própria. Uma Execution em `verifying` só recebe esse envelope; o host deve iniciar a Sub-Run real correspondente e registrar a telemetria dela. O framework não cria Run, Call, custo ou resultado sintético quando o host não a executa.\n\nO status técnico da Run/Sub-Run (`completed`, `failed`, `cancelled`) é diferente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`). Uma Run tecnicamente concluída pode bloquear a Task porque um gate ou Evidence não passou.\n\nUma observação por AC não altera esse lifecycle nem substitui os gates. Ela é\numa declaração versionada cujo vínculo só pode complementar Evidence quando\n`confirmed` e coerente; os demais estados preservam pendência ou falha. Veja o\n[contrato de prova observável](../../skills/zaip-skill-change/references/observable-evidence.md).\n\nDepois de capturar a decisão real do finalizador, o orquestrador pode aplicar\no fechamento pela CLI. O trecho abaixo **não** funciona como atalho para\n`task block` ou `run finish` sem essa decisão já persistida:\n\n```bash\nzaip run finish RUN-ID \\\n  --status completed \\\n  --task-outcome blocked \\\n  --summary "Gate de integração pendente"\nzaip run closure RUN-ID\n```\n\n## Fechamento e retomada de Tasks\n\nAntes do último Gui, consulte o [preflight do guia 16](16-lifecycle-e-reconciliacao.md#diagnóstico-antecipado-e-respostas-compactas).\nEle separa autoridade para `completed`, descendentes ativos e prontidão de\ndespacho; não substitui decisão nem gates. Recuperação pós-publicação revalida\nrecibo, publicação e proprietário único; observação passiva elegível não é outro\nexecutor. Em `same_turn_handoff`, a telemetria física é atribuída uma única vez,\nconforme o [guia 27](27-telemetria-git-native.md). Saída compacta preserva o cálculo\ninterno e não comprova menor duração.\n\nAntes de uma Run raiz terminar, sua Task deve estar em um destes estados:\n\n- `completed`: resultado e gates aprovados;\n- `blocked`: inconclusão retomável, dependência externa ou gate insuficiente;\n- `failed`: erro técnico/integridade que impediu a execução válida;\n- `cancelled`: pedido humano explícito.\n\n`executing` e `verifying` nunca são estados válidos no fim **formalmente persistido** da tentativa. Use `task resume` para `blocked` e `task rework` para `failed`; ambas preservam a Task, e cada nova entrada em execução incrementa a tentativa. `completed` e `cancelled` não reabrem.\n\nInterromper a geração exige recuperação retomável; quando o evento de\ninterrupção for observado e a escrita funcionar, o alvo é `blocked`. Morte\nabrupta do processo pode deixar o estado pendente até o próximo evento\nobservável, como descrito acima. “Cancelar a Task” é decisão explícita e\nresulta em `cancelled` somente quando persistida.\n\n## Agregação de SPEC e PRD\n\nQuando a primeira Task filha inicia, SPEC e PRD relacionados passam para `active` e permanecem em Execução enquanto restar trabalho macro, inclusive entre Runs. O resultado isolado de uma Task não terminaliza o pai.\n\n- Task bloqueada/falhada mantém o macro em Execução para que outras Tasks e decisões parentais continuem.\n- SPEC/PRD aguardam todas as Tasks e Runs filhas.\n- Depois que todas as Tasks da DAG ficam terminais, o macro pode entrar em\n  Verificação quando todas concluíram; bloqueios/falhas e dependentes inviáveis\n  são fechados com causa antes de decidir o resultado parental.\n- Delivery exige gates, integração, Acceptance Criteria, outcomes e Evidence\n  próprios do pai. Um pai não é `delivered` se uma filha bloqueou/falhou.\n\n## Reconciliação manual\n\nO dashboard executa `zaip run reconcile --open --json` somente depois que o usuário confirma o popup Reconciliar. Não há reconciliação **global** ao abrir o dashboard, em cada turno ou em intervalo automático. O contrato-alvo v4 acrescenta conciliação **direcionada à tentativa atual** no fechamento/Stop observado ou no próximo evento Codex da mesma Task, nunca uma varredura global silenciosa.\n\nO algoritmo é idempotente e conservador:\n\n- `task_complete` local exato permite finalizar tecnicamente a Run e tentar os gates;\n- gate insuficiente produz `blocked`, nunca sucesso inventado;\n- Run sem invocação ativa por dez minutos é órfã e termina como `failed`;\n- `cancelled` nunca é inferido;\n- Tasks apenas prontas, sem Run terminal atribuída, não são reavaliadas como travadas.\n\nO hook pre-write é diferente da reconciliação: ele verifica localmente se o turno atual possui Run raiz e Task em execução antes de permitir mutação. Essa checagem não chama modelo, não consome tokens e não percorre o backlog.\n\n## Projeção no dashboard\n\nEm Operação e Monitor de Custos, “Chamadas do agente orquestrador” e “Chamadas de subagentes” possuem filtros separados. A tabela de Executions agrega, sem dupla contagem, Runs de orquestrador, Sub-Runs, Sub-Runs finalizadores, Tasks finalizadas e Calls de LLM conhecidas. Quando nem todas as Calls são observáveis, a contagem é marcada como parcial em vez de assumir zero.\n\nTrabalho possui duas leituras da mesma projeção: Trabalho (Kanban), por estágio, e Trabalho (Lista), tabular. As duas mantêm os filtros Todas as Tarefas, Visão Unificada Geral, PRDs, SPECs e Tarefas Avulsas. A lista expõe indicadores operacionais por item, incluindo status, origem, Runs, Sub-Runs, duração, tokens, custo e cobertura.\n\nCada segmento de telemetria possui uma chave de origem e só pode ser atribuído uma vez. Correções de duplicidade preservam o evento histórico e registram uma supersessão; projeções nunca devem somar os dois eventos.\n\n## Persistência compacta da telemetria\n\nMicroeventos observáveis do Codex são sanitizados e gravados primeiro no spool local ignorado pelo\nGit. Depois de um terminal ou erro, eles são compactados em um `InvocationSummaryV1` por invocação\nde agente. Os summaries são organizados em chunks imutáveis e manifestos mensais por writer em\n`.agents/records/telemetry/<ano>/<mês>/writers/<writer-id>/`.\n\nEssa compactação não substitui o ledger `RUN-*`: a Run continua sendo a fonte de lifecycle,\natribuição e evidência. O summary é a fonte compacta de métricas observadas. O Dashboard combina as\nduas leituras sem dupla contagem; tokens e custos do summary são autoritativos quando válidos, mas\numa duração delimitada do lifecycle é preservada se a fonte compacta não conhece a duração.\n\nCobertura é independente por métrica. Tokens, Calls, custo, duração e latência podem ter estados\ndiferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar\njuntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e\nrecuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).\n\n## Recuperação e autonomia v1\n\nO [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui\ne o relay antes do Stop: não exija que um finalizador read-only permaneça\nativo esperando recibos. Ele é último filho direto do responsável da Task,\nnão de cada executor. Um orquestrador delegado conserva a ancestry real.\n\nOs [presets](19-assurance-e-autonomia.md) pertencem à Task estável:\nEssencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`\nnão renovam quota; `attempt_count` do lifecycle não substitui o diário\nde reservas do runtime. Ausência de Evidence é bloqueio, erro técnico\ncomprovado é falha e tempo não determina abandono.\n\nFechamento técnico, estado canônico da Task, projeções e entrega parental\nprecisam ser confirmados separadamente. A exceção de raiz avulsa direta\nautorizada pertence à compatibilidade do contrato atual; no padrão Codex-native\nda v4, a Task avulsa terá executor subagente nativo observado. Nenhum dos dois\ncaminhos dispensa Evidence, gates e decisão real de Gui.\n\n## Regra operacional de checkout e release\n\nBranch é uma linha de commits; worktree é outra pasta de checkout que pode apontar para uma branch. Task avulsa ou PRD/SPEC serial usa um único checkout e um escritor por Task/Run registrado na raiz Git comum. Assim, uma edição pequena não cria branch. Só frentes paralelas independentes, com concorrência ativa, dependências resolvidas e `write_scopes` disjuntos, recebem branch e worktree separados. Um teste isolado pode usar worktree detached temporário em `.agents/private/state/worktrees/validation`.\n\nNo fim da Task isolada, integre trabalho concluído, inventarie arquivos e ignorados, faça bundle/snapshot verificáveis em `.agents/private/state/backup-branchs` e `.agents/private/state/backup-worktrees` e feche branch/worktree. Se a Task estiver bloqueada, preserve o trabalho no backup antes de liberar o checkout. A limpeza dos backups é manual. No checkout compartilhado, alterações de várias Tasks sem atribuição verificável bloqueiam fechamento automático.\n\nO ciclo em `.agents/config/release-cycle.json` admite drafts de PRD/SPEC futuros, mas execução só do release corrente. `freeze`, `audit` e `advance` exigem prova de SHA, estado canônico e branches/worktrees. Para release/crítico, checks locais fixos antecedem o push de `main`; CI remoto do mesmo SHA antecede a Release. A exceção de uma Task de coordenação de release exige identidade explícita no manifesto congelado, Run ativa no freeze, risco crítico, alvo corrente e escopos somente de release. Ela termina e integra seus records no candidato antes de `audit`; audit/advance conferem os records no SHA. Até a auditoria ficar verde, o release permanece pendente.\n',M=e(t(),1),N=`# ZAIP-AIOS (6 Squads + 23 Agents)
 
 [English](README-ENG.md) | Português
 
@@ -2526,6 +2557,10 @@ matriz de performance aprovada apenas porque consultas focadas passaram.
 
 ## Visão rápida
 
+O cofre padrão de credenciais do backend é o **Infisical self-hosted**. A [skill e seus guias](.agents/skills/zaip-skill-infisical/SKILL.md) incluem preparação de instalação com Docker Compose, identidades de máquina, criação/importação sem sobrescrita, uso de credenciais existentes e backup/restore. O runner entrega valores somente ao processo autorizado, sem retorná-los ao agente. O core gratuito não inclui automaticamente recursos Enterprise; infraestrutura e backups têm custos próprios. O init configura o padrão, sem instalar serviços nem acessar segredos.
+
+A [correção de reuso e lint antecipado](docs/quality/v63-reuso-testes-e-lint.md) preserva grupos de testes aprovados quando um grupo posterior falha, desde que candidato, entradas, ferramentas e dependências permaneçam válidos. O lint público passa a integrar os 21 gates essenciais e executa antes dos contratos e builds caros. O teste de retomada demonstra duas execuções repetidas evitadas em uma fixture; não representa uma promessa de economia em horas nem aprovação parcial de release.
+
 As mudanças da v6.2 estão descritas no [contrato de modelos e publicação](docs/quality/v62-modelos-e-publicacao.md): novas rotas Sol 6.1, migração de configurações com preservação do histórico, critérios de Luna/high e reconhecimento dos pedidos diretos de ajustes com publicação. A identidade local não substitui a verificação da Release e do pacote npm.
 
 A v6.0 trata a [recuperação de estados parciais e fechamentos sequenciais](docs/quality/v60-recuperacao.md), a [identidade da instalação no cache](docs/quality/v60-eficiencia.md) e o [planejamento explícito de major](docs/quality/v60-ciclo-major.md). O [plano de aceite](docs/quality/v60-plano-de-aceite.md) distingue testes locais, provas do candidato, publicação e fechamento histórico; notas e economia exigem resultados observados.
@@ -2739,7 +2774,7 @@ Use \`npx @zaip-ai/cli@latest init --profile lite\` para instalar esse perfil. U
 
 O comando instala a versão pública mais recente do ZAIP-AIOS, prepara as dependências ausentes do perfil selecionado e preserva as versões de pacotes existentes no projeto. Alterações deste código-fonte só chegam ao comando \`@latest\` depois de publicadas no npm.
 
-A instalação inclui Dashboard, regras, skills e configurações para Codex e Claude. Execute o mesmo comando novamente para atualizar os arquivos gerenciados sem apagar o histórico.
+A instalação inclui Dashboard, regras, skills e configurações para Codex, sem perguntar qual cliente usar. Claude é opcional e só é habilitado com pedido explícito: \`npx @zaip-ai/cli@latest init --claude\`. A opção instala os adapters, não o aplicativo Claude Code. Atualizações preservam a seleção existente dos clientes e o histórico.
 
 O pacote Redis inclui apenas o cliente JavaScript; o servidor deve ser configurado separadamente.
 

package/templates/.agents/dashboard/apps/frontend/dist/assets/{PricingSettingsDialog-DlkxF4w_.js → PricingSettingsDialog-DsFTUwhL.js}

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{n as r}from"./dashboard-localization-CqicG5jJ.js";var i=e(t(),1),a=n();function o({catalog:e,fxRate:t,locale:n,onClose:o,onSave:c,onSaveFxRate:l}){let u=r[n],[d,f]=(0,i.useState)(e),[p,m]=(0,i.useState)(t?.rate??0),[h,g]=(0,i.useState)(!1),_=(e,t)=>f(n=>({...n,models:n.models.map((n,r)=>r===e?{...n,...t}:n)})),v=e=>Math.max(0,Number(e)||0);return(0,a.jsx)(`main`,{className:`pricing-backdrop`,children:(0,a.jsxs)(`section`,{"aria-labelledby":`pricing-page-title`,className:`pricing-dialog`,children:[(0,a.jsxs)(`header`,{children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`small`,{children:u.eyebrow}),(0,a.jsx)(`h1`,{id:`pricing-page-title`,children:u.title}),(0,a.jsx)(`p`,{children:u.description})]}),(0,a.jsxs)(`button`,{className:`pricing-back-button`,onClick:o,type:`button`,children:[(0,a.jsx)(`span`,{"aria-hidden":`true`,children:`←`}),` `,u.back]})]}),(0,a.jsxs)(`div`,{className:`pricing-fx-settings`,children:[(0,a.jsxs)(`div`,{className:`pricing-fx-copy`,children:[(0,a.jsx)(`strong`,{children:u.fxTitle}),(0,a.jsx)(`p`,{children:u.fxDescription})]}),(0,a.jsxs)(`label`,{children:[(0,a.jsx)(`span`,{children:u.fxLabel}),(0,a.jsxs)(`div`,{className:`pricing-fx-input`,children:[(0,a.jsx)(`span`,{children:`R$`}),(0,a.jsx)(`input`,{"aria-label":u.fxAriaLabel,min:`0.0001`,onChange:e=>m(Math.max(1e-4,Number(e.target.value)||0)),step:`0.0001`,type:`number`,value:p})]})]})]}),(0,a.jsxs)(`div`,{className:`pricing-table-heading`,children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`strong`,{children:u.catalog}),(0,a.jsx)(`p`,{children:u.pricesPerMillion})]}),(0,a.jsxs)(`span`,{children:[d.models.length,` `,u.models]})]}),(0,a.jsx)(`div`,{className:`pricing-table-wrap`,children:(0,a.jsxs)(`table`,{children:[(0,a.jsx)(`thead`,{children:(0,a.jsxs)(`tr`,{children:[(0,a.jsx)(`th`,{children:u.model}),(0,a.jsx)(`th`,{children:u.provider}),(0,a.jsx)(`th`,{children:u.input}),(0,a.jsx)(`th`,{children:u.cache}),(0,a.jsx)(`th`,{children:u.output}),(0,a.jsx)(`th`,{children:u.reasoning}),(0,a.jsx)(`th`,{children:u.priorityInput}),(0,a.jsx)(`th`,{children:u.priorityCache}),(0,a.jsx)(`th`,{children:u.priorityOutput}),(0,a.jsx)(`th`,{children:u.priorityReasoning}),(0,a.jsx)(`th`,{children:u.contextLimit}),(0,a.jsx)(`th`,{children:u.inputMultiplier}),(0,a.jsx)(`th`,{children:u.outputMultiplier}),(0,a.jsx)(`th`,{})]})}),(0,a.jsx)(`tbody`,{children:d.models.map((e,t)=>(0,a.jsxs)(`tr`,{children:[(0,a.jsxs)(`td`,{children:[(0,a.jsx)(`input`,{"aria-label":u.model,onChange:e=>_(t,{id:e.target.value}),value:e.id}),(0,a.jsx)(`small`,{children:e.aliases.join(`, `)||u.noAliases})]}),(0,a.jsx)(`td`,{children:(0,a.jsxs)(`select`,{onChange:e=>_(t,{provider:e.target.value}),value:e.provider,children:[(0,a.jsx)(`option`,{value:`openai`,children:`OpenAI`}),(0,a.jsx)(`option`,{value:`anthropic`,children:`Anthropic`})]})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.input_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{cached_input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.cached_input_per_million_usd??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{output_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.output_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{reasoning_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.reasoning_per_million_usd??0})}),[`priority_input_per_million_usd`,`priority_cached_input_per_million_usd`,`priority_output_per_million_usd`,`priority_reasoning_per_million_usd`].map(n=>(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{[n]:v(e.target.value)}),step:`0.001`,type:`number`,value:e[n]??0})},n)),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{long_context_threshold_tokens:v(e.target.value)||null}),step:`1`,type:`number`,value:e.long_context_threshold_tokens??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_input_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_input_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_output_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_output_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`button`,{"aria-label":u.removeModel,onClick:()=>f(e=>({...e,models:e.models.filter((e,n)=>n!==t)})),type:`button`,children:`×`})})]},e.id))})]})}),(0,a.jsxs)(`footer`,{children:[(0,a.jsxs)(`button`,{onClick:()=>f(e=>({...e,models:[...e.models,s(n)]})),type:`button`,children:[`+ `,u.addModel]}),(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`button`,{onClick:o,type:`button`,children:u.cancel}),(0,a.jsx)(`button`,{disabled:h,onClick:async()=>{g(!0);try{await c(d),await l(p),o()}finally{g(!1)}},type:`button`,children:h?u.saving:u.save})]})]})]})})}function s(e=`pt-BR`){let t=r[e];return{id:t.newModel,provider:`openai`,aliases:[],input_per_million_usd:0,cached_input_per_million_usd:0,output_per_million_usd:0,reasoning_per_million_usd:0,priority_input_per_million_usd:null,priority_cached_input_per_million_usd:null,priority_output_per_million_usd:null,priority_reasoning_per_million_usd:null,reasoning_billed_separately:!1,long_context_threshold_tokens:null,long_context_input_multiplier:1,long_context_output_multiplier:1,source_label:t.manualOverride,source_url:`https://developers.openai.com/api/docs/pricing`,notes:[t.editedNote]}}export{o as PricingSettingsPage};
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-YfoKMzCQ.js";import{n as r}from"./dashboard-localization-BVBhiAAS.js";var i=e(t(),1),a=n();function o({catalog:e,fxRate:t,locale:n,onClose:o,onSave:c,onSaveFxRate:l}){let u=r[n],[d,f]=(0,i.useState)(e),[p,m]=(0,i.useState)(t?.rate??0),[h,g]=(0,i.useState)(!1),_=(e,t)=>f(n=>({...n,models:n.models.map((n,r)=>r===e?{...n,...t}:n)})),v=e=>Math.max(0,Number(e)||0);return(0,a.jsx)(`main`,{className:`pricing-backdrop`,children:(0,a.jsxs)(`section`,{"aria-labelledby":`pricing-page-title`,className:`pricing-dialog`,children:[(0,a.jsxs)(`header`,{children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`small`,{children:u.eyebrow}),(0,a.jsx)(`h1`,{id:`pricing-page-title`,children:u.title}),(0,a.jsx)(`p`,{children:u.description})]}),(0,a.jsxs)(`button`,{className:`pricing-back-button`,onClick:o,type:`button`,children:[(0,a.jsx)(`span`,{"aria-hidden":`true`,children:`←`}),` `,u.back]})]}),(0,a.jsxs)(`div`,{className:`pricing-fx-settings`,children:[(0,a.jsxs)(`div`,{className:`pricing-fx-copy`,children:[(0,a.jsx)(`strong`,{children:u.fxTitle}),(0,a.jsx)(`p`,{children:u.fxDescription})]}),(0,a.jsxs)(`label`,{children:[(0,a.jsx)(`span`,{children:u.fxLabel}),(0,a.jsxs)(`div`,{className:`pricing-fx-input`,children:[(0,a.jsx)(`span`,{children:`R$`}),(0,a.jsx)(`input`,{"aria-label":u.fxAriaLabel,min:`0.0001`,onChange:e=>m(Math.max(1e-4,Number(e.target.value)||0)),step:`0.0001`,type:`number`,value:p})]})]})]}),(0,a.jsxs)(`div`,{className:`pricing-table-heading`,children:[(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`strong`,{children:u.catalog}),(0,a.jsx)(`p`,{children:u.pricesPerMillion})]}),(0,a.jsxs)(`span`,{children:[d.models.length,` `,u.models]})]}),(0,a.jsx)(`div`,{className:`pricing-table-wrap`,children:(0,a.jsxs)(`table`,{children:[(0,a.jsx)(`thead`,{children:(0,a.jsxs)(`tr`,{children:[(0,a.jsx)(`th`,{children:u.model}),(0,a.jsx)(`th`,{children:u.provider}),(0,a.jsx)(`th`,{children:u.input}),(0,a.jsx)(`th`,{children:u.cache}),(0,a.jsx)(`th`,{children:u.output}),(0,a.jsx)(`th`,{children:u.reasoning}),(0,a.jsx)(`th`,{children:u.priorityInput}),(0,a.jsx)(`th`,{children:u.priorityCache}),(0,a.jsx)(`th`,{children:u.priorityOutput}),(0,a.jsx)(`th`,{children:u.priorityReasoning}),(0,a.jsx)(`th`,{children:u.contextLimit}),(0,a.jsx)(`th`,{children:u.inputMultiplier}),(0,a.jsx)(`th`,{children:u.outputMultiplier}),(0,a.jsx)(`th`,{})]})}),(0,a.jsx)(`tbody`,{children:d.models.map((e,t)=>(0,a.jsxs)(`tr`,{children:[(0,a.jsxs)(`td`,{children:[(0,a.jsx)(`input`,{"aria-label":u.model,onChange:e=>_(t,{id:e.target.value}),value:e.id}),(0,a.jsx)(`small`,{children:e.aliases.join(`, `)||u.noAliases})]}),(0,a.jsx)(`td`,{children:(0,a.jsxs)(`select`,{onChange:e=>_(t,{provider:e.target.value}),value:e.provider,children:[(0,a.jsx)(`option`,{value:`openai`,children:`OpenAI`}),(0,a.jsx)(`option`,{value:`anthropic`,children:`Anthropic`})]})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.input_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{cached_input_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.cached_input_per_million_usd??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{output_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.output_per_million_usd})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{reasoning_per_million_usd:v(e.target.value)}),step:`0.001`,type:`number`,value:e.reasoning_per_million_usd??0})}),[`priority_input_per_million_usd`,`priority_cached_input_per_million_usd`,`priority_output_per_million_usd`,`priority_reasoning_per_million_usd`].map(n=>(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{[n]:v(e.target.value)}),step:`0.001`,type:`number`,value:e[n]??0})},n)),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0`,onChange:e=>_(t,{long_context_threshold_tokens:v(e.target.value)||null}),step:`1`,type:`number`,value:e.long_context_threshold_tokens??0})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_input_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_input_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`input`,{min:`0.001`,onChange:e=>_(t,{long_context_output_multiplier:Math.max(.001,Number(e.target.value)||1)}),step:`0.1`,type:`number`,value:e.long_context_output_multiplier})}),(0,a.jsx)(`td`,{children:(0,a.jsx)(`button`,{"aria-label":u.removeModel,onClick:()=>f(e=>({...e,models:e.models.filter((e,n)=>n!==t)})),type:`button`,children:`×`})})]},e.id))})]})}),(0,a.jsxs)(`footer`,{children:[(0,a.jsxs)(`button`,{onClick:()=>f(e=>({...e,models:[...e.models,s(n)]})),type:`button`,children:[`+ `,u.addModel]}),(0,a.jsxs)(`div`,{children:[(0,a.jsx)(`button`,{onClick:o,type:`button`,children:u.cancel}),(0,a.jsx)(`button`,{disabled:h,onClick:async()=>{g(!0);try{await c(d),await l(p),o()}finally{g(!1)}},type:`button`,children:h?u.saving:u.save})]})]})]})})}function s(e=`pt-BR`){let t=r[e];return{id:t.newModel,provider:`openai`,aliases:[],input_per_million_usd:0,cached_input_per_million_usd:0,output_per_million_usd:0,reasoning_per_million_usd:0,priority_input_per_million_usd:null,priority_cached_input_per_million_usd:null,priority_output_per_million_usd:null,priority_reasoning_per_million_usd:null,reasoning_billed_separately:!1,long_context_threshold_tokens:null,long_context_input_multiplier:1,long_context_output_multiplier:1,source_label:t.manualOverride,source_url:`https://developers.openai.com/api/docs/pricing`,notes:[t.editedNote]}}export{o as PricingSettingsPage};

package/templates/.agents/dashboard/apps/frontend/dist/assets/ProjectSettingsPage-BCsdQtWG.js

@@ -0,0 +1,3 @@
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,_ as n,v as r,w as i,y as a}from"./cost-monitor-YfoKMzCQ.js";import{t as o}from"./index-uIVtG2ZR.js";var s=e(t(),1),c=i();function l({children:e,className:t=``,title:n}){return(0,c.jsxs)(`section`,{className:`project-settings-card ${t}`,children:[(0,c.jsx)(`h2`,{children:n}),(0,c.jsx)(`div`,{className:`project-settings-fields`,children:e})]})}function u({children:e,className:t=``,hint:n,label:r}){return(0,c.jsxs)(`div`,{className:`project-settings-field ${t}`,children:[(0,c.jsx)(`span`,{children:r}),e,n?(0,c.jsx)(`small`,{children:n}):null]})}var d=[{id:`primary_language`,defaultName:`TypeScript`,scope:`backend`},{id:`backend_runtime`,defaultName:`Node.js`,scope:`backend`},{id:`backend_api`,defaultName:`Hono`,scope:`backend`},{id:`query_builder`,defaultName:`Kysely`,scope:`backend`},{id:`database`,defaultName:`PostgreSQL via Supabase`,scope:`backend`},{id:`auth_storage`,defaultName:`Supabase Auth + Storage`,scope:`backend`},{id:`backend_secrets`,defaultName:`Infisical self-hosted`,scope:`backend`},{id:`cache_messaging`,defaultName:`Redis`,scope:`backend`},{id:`async_queue`,defaultName:`BullMQ`,scope:`backend`},{id:`backend_infrastructure`,defaultName:`Terraform`,scope:`backend`},{id:`backend_hosting`,defaultName:`Hostinger VPS`,scope:`backend`},{id:`web_framework`,defaultName:`React`,scope:`frontend`},{id:`web_language`,defaultName:`TypeScript`,scope:`frontend`},{id:`web_build`,defaultName:`Vite`,scope:`frontend`},{id:`frontend_hosting`,defaultName:`Cloudflare Pages`,scope:`frontend`},{id:`site_framework`,defaultName:`Astro`,scope:`site`},{id:`site_language`,defaultName:`TypeScript`,scope:`site`},{id:`site_islands`,defaultName:`React Islands`,scope:`site`},{id:`site_build`,defaultName:`Vite`,scope:`site`},{id:`site_hosting`,defaultName:`Cloudflare Pages`,scope:`site`},{id:`prometheus`,defaultName:`Prometheus`,scope:`observability`},{id:`grafana`,defaultName:`Grafana`,scope:`observability`},{id:`uptime_kuma`,defaultName:`Uptime Kuma`,scope:`observability`},{id:`cadvisor`,defaultName:`cAdvisor`,scope:`observability`},{id:`node_exporter`,defaultName:`node-exporter`,scope:`observability`},{id:`redis_exporter`,defaultName:`Redis Exporter`,scope:`observability`},{id:`k6`,defaultName:`k6`,scope:`testing`},{id:`autocannon`,defaultName:`autocannon`,scope:`testing`}],f=new Set([`database`,`auth_storage`,`backend_secrets`,`backend_hosting`,`frontend_hosting`,`site_hosting`]);function p(e){return f.has(e)}function m(e){let{languages:t,components:n,...r}=e.stack.overrides,i=w(n)?n:{};return{components:Object.fromEntries(d.map(e=>{let t=i[e.id],n=w(t)?t:{};return[e.id,{name:C(n.name)||e.defaultName,version:C(n.version),reference:C(n.reference)}]})),otherOverrides:JSON.stringify(r,null,2)}}function h(e,t){let n=new Map(t.filter(e=>e.installation===`installed`&&e.version!==null).map(e=>[e.name.toLowerCase(),e.version]));return Object.fromEntries(d.map(t=>{let r=e[t.id],i=n.get(x(t.id));return[t.id,r.version!==``||i===void 0?r:{...r,version:i}]}))}function g(e,t,n){if(e.autonomy?.version===1&&e.execution&&e.execution.runtime!==`manual`&&e.execution.runtime!==`codex_native`&&e.execution.autonomous.provider!==`codex`)throw Error(`Autonomy-v1 exige Codex na execução gerenciada / requires Codex for managed execution. Selecione Codex; conversas diretas continuam disponíveis.`);let r=JSON.parse(n);if(!w(r))throw Error(`Demais overrides deve ser um objeto JSON.`);let{languages:i,components:a,...o}=r;for(let e of d){let n=t[e.id].version.trim();if(n!==``&&!p(e.id)&&!/^\d+\.\d+(?:\.\d+)?(?:[-+][0-9A-Za-z.-]+)?$/.test(n))throw Error(`A versão de ${t[e.id].name||e.defaultName} deve ser exata, como 22.16.0 ou 17.6, sem ^, ~, >= ou latest.`);if(p(e.id)&&(n.length>120||/[\r\n]/.test(n)))throw Error(`A referência de ${t[e.id].name||e.defaultName} deve ter uma única linha com até 120 caracteres.`)}let s=Object.fromEntries(d.map(e=>[e.id,{name:t[e.id].name.trim()||e.defaultName,version:t[e.id].version.trim(),reference:t[e.id].reference.trim()}])),c=w(e.stack.overrides.components)?e.stack.overrides.components:{};return{...e,stack:{...e.stack,overrides:{...o,components:{...c,...s},languages:{frontend:S(s,`frontend`),backend:S(s,`backend`),site:S(s,`site`)}}}}}function _(e){return[...new Set(e.split(/\r?\n/).map(e=>e.trim()).filter(Boolean))]}function v(){return{runtime:`autonomous`,autonomous:{provider:`codex`,model:`gpt-6.1-sol`,max_parallelism:1,lease_ms:6e4}}}function y(e){if(e===`manual`)return{runtime:`manual`};if(e===`codex_native`)return{runtime:`codex_native`};if(e!==`managed`&&e!==`autonomous`)throw Error(`Unknown runtime: ${e}`);return{...v(),runtime:e}}function b(e){let t=e?.match(/^v?(\d+)\.(\d+)\.\d+(?:[-+][0-9A-Za-z.-]+)?$/);return t?`v${t[1]}.${t[2]}`:null}function x(e){return e===`backend_runtime`?`node.js`:e===`backend_api`?`hono`:e===`site_framework`?`astro`:e===`cache_messaging`?`redis`:e===`async_queue`?`bullmq`:e===`web_framework`||e===`site_islands`?`react`:e===`web_build`||e===`site_build`?`vite`:e===`primary_language`||e===`web_language`||e===`site_language`?`typescript`:``}function S(e,t){return[...new Set(d.filter(e=>e.scope===t).map(t=>e[t.id].name.trim()).filter(Boolean))]}function C(e){return typeof e==`string`?e:``}function w(e){return typeof e==`object`&&!!e&&!Array.isArray(e)}var T={primary_language:{pt:`Linguagem principal`,en:`Primary language`},backend_runtime:{pt:`Runtime backend`,en:`Backend runtime`},backend_api:{pt:`Framework backend / API`,en:`Backend framework / API`},query_builder:{pt:`Query builder`,en:`Query builder`},database:{pt:`Banco de dados`,en:`Database`},auth_storage:{pt:`Autenticação e Storage`,en:`Authentication and Storage`},backend_secrets:{pt:`Gestão de credenciais`,en:`Secrets management`},cache_messaging:{pt:`Cache e mensageria`,en:`Cache and messaging`},async_queue:{pt:`Filas e processamento assíncrono`,en:`Queues and async processing`},backend_infrastructure:{pt:`Infraestrutura backend`,en:`Backend infrastructure`},backend_hosting:{pt:`Hospedagem do backend`,en:`Backend hosting`},web_framework:{pt:`Framework do Web App`,en:`Web App framework`},web_language:{pt:`Linguagem do Web App`,en:`Web App language`},web_build:{pt:`Build do Web App`,en:`Web App build`},frontend_hosting:{pt:`Hospedagem do frontend`,en:`Frontend hosting`},site_framework:{pt:`Framework do site`,en:`Site framework`},site_language:{pt:`Linguagem do site`,en:`Site language`},site_islands:{pt:`Componentes interativos`,en:`Interactive components`},site_build:{pt:`Build do site`,en:`Site build`},site_hosting:{pt:`Hospedagem do site`,en:`Site hosting`},prometheus:{pt:`Coleta de métricas`,en:`Metrics collection`},grafana:{pt:`Dashboards`,en:`Dashboards`},uptime_kuma:{pt:`Monitoramento de disponibilidade`,en:`Availability monitoring`},cadvisor:{pt:`Métricas de containers`,en:`Container metrics`},node_exporter:{pt:`Métricas de host`,en:`Host metrics`},redis_exporter:{pt:`Métricas do Redis`,en:`Redis metrics`},k6:{pt:`Teste de carga`,en:`Load testing`},autocannon:{pt:`Teste HTTP de carga`,en:`HTTP load testing`}};function E({components:e,locale:t,onChange:n,referenceHint:r,versionHint:i}){let a=[{scope:`backend`,title:t===`pt-BR`?`Backend e dados`:`Backend and data`},{scope:`frontend`,title:`Web App`},{scope:`site`,title:t===`pt-BR`?`Site e landing pages`:`Site and landing pages`},{scope:`observability`,title:t===`pt-BR`?`Observabilidade`:`Observability`},{scope:`testing`,title:t===`pt-BR`?`Testes sob demanda`:`On-demand testing`}],o=(t,r,i)=>n({...e,[t]:{...e[t],[r]:i}});return(0,c.jsxs)(`div`,{className:`project-stack-editor`,children:[a.map(n=>(0,c.jsxs)(`section`,{children:[(0,c.jsx)(`h3`,{children:n.title}),(0,c.jsxs)(`div`,{className:`project-stack-table`,children:[(0,c.jsxs)(`div`,{className:`project-stack-table-head`,"aria-hidden":`true`,children:[(0,c.jsx)(`span`,{children:`Item`}),(0,c.jsx)(`span`,{children:t===`pt-BR`?`Tecnologia`:`Technology`}),(0,c.jsx)(`span`,{children:t===`pt-BR`?`Versão atual / referência`:`Current version / reference`}),(0,c.jsx)(`span`,{children:t===`pt-BR`?`Pacote / imagem / serviço`:`Package / image / service`})]}),d.filter(e=>e.scope===n.scope).map(n=>(0,c.jsxs)(`div`,{className:`project-stack-row`,children:[(0,c.jsx)(`strong`,{children:T[n.id][t===`pt-BR`?`pt`:`en`]}),(0,c.jsx)(`input`,{"aria-label":`${T[n.id].pt}: tecnologia`,value:e[n.id].name,onChange:e=>o(n.id,`name`,e.target.value)}),(0,c.jsx)(`input`,{"aria-label":`${T[n.id].pt}: ${p(n.id)?`versão atual ou referência`:`versão exata`}`,className:p(n.id)?`is-reference-value`:void 0,inputMode:p(n.id)?`text`:`decimal`,placeholder:p(n.id)?t===`pt-BR`?`Serviço em nuvem`:`Cloud service`:`x.y.z`,title:p(n.id)?e[n.id].version:void 0,value:e[n.id].version,onChange:e=>o(n.id,`version`,e.target.value)}),(0,c.jsx)(`input`,{"aria-label":`${T[n.id].pt}: referência`,placeholder:`npm:pacote ou service:nome`,value:e[n.id].reference,onChange:e=>o(n.id,`reference`,e.target.value)})]},n.id))]})]},n.scope)),(0,c.jsxs)(`div`,{className:`project-stack-format-help`,children:[(0,c.jsxs)(`p`,{children:[(0,c.jsx)(`strong`,{children:t===`pt-BR`?`Formato da versão:`:`Version format:`}),` `,i]}),(0,c.jsxs)(`p`,{children:[(0,c.jsx)(`strong`,{children:t===`pt-BR`?`Formato da referência:`:`Reference format:`}),` `,r]})]})]})}function D({components:e,showTitle:t=!0,text:n}){return e.length===0?null:(0,c.jsxs)(`section`,{className:`project-stack-versions`,"aria-label":n.versions,children:[t?(0,c.jsx)(`h3`,{children:n.versions}):null,(0,c.jsx)(`div`,{children:e.map(e=>(0,c.jsxs)(`article`,{children:[(0,c.jsxs)(`div`,{className:`project-stack-version-identity`,children:[(0,c.jsx)(`strong`,{children:e.name}),(0,c.jsxs)(`code`,{children:[n.current,`: `,e.version??n.versionUnavailable]}),e.configured_version!==null&&e.configured_version!==e.version?(0,c.jsxs)(`code`,{children:[n.configured,`: `,e.configured_version]}):null]}),(0,c.jsx)(`span`,{className:`is-${e.verification}`,children:e.installation===`runtime`?n.runtime:e.installation===`installed`?n.installed:e.installation===`bundled`?n.bundled:n.missing}),e.source?(0,c.jsx)(`small`,{children:e.source}):null]},e.name))})]})}function O(e){return{health:e.health??{state:`unknown`,scope:`settings_runtime`},dependencies:k(e.dependencies,e.dependencies?.installed),documentation:k(e.documentation,e.documentation?.available),profile:e.installation_profile??null,hasMissingDependencies:(A(e.dependencies?.missing)??0)>0}}function k(e,t){let n=e?.state??`unknown`,r=A(e?.percent);return{completed:A(t),total:A(e?.applicable),percentage:(n===`complete`||n===`incomplete`)&&r!==null&&r<=100?r:null,state:n}}function A(e){return typeof e==`number`&&Number.isFinite(e)&&e>=0?e:null}function j(e){return e.filter(e=>![`database`,`installation`].includes(e.id))}var M={"pt-BR":{eyebrow:`Configurações`,title:`Configuração do projeto`,intro:`Edite o arquivo central do projeto com validação do schema antes da gravação.`,loading:`Carregando…`,loadError:`Não foi possível carregar as configurações do projeto.`,retry:`Tentar novamente`,back:`Voltar ao dashboard`,save:`Salvar configurações`,saving:`Validando e salvando…`,saved:`Configurações salvas e validadas.`,framework:`Framework ZAIP-AIOS`,frameworkHint:`Ativa ou desativa o framework para este projeto.`,identity:`Identidade do projeto`,workspacePath:`Caminho do projeto`,workspacePathHint:`Pasta local usada por esta instância do Dashboard.`,workspacePathLoading:`Identificando caminho…`,workspacePathUnavailable:`Caminho indisponível`,stack:`Stack e linguagens`,execution:`Execução`,assurance:`Assurance`,executionToggleHint:`Grava ou remove o bloco execution. Sem ele, o projeto usa execução manual.`,runtimeHint:`Managed gerencia PRDs/SPECs e mantém avulsas diretas. Manual não inicia provider; autonomous permite execução gerenciada também para Task avulsa por comando explícito.`,providerHint:`Provider que inicia os agentes da execução autônoma: Codex ou Claude.`,autonomyProviderHint:`Autonomy-v1 exige Codex para execução gerenciada. Claude continua disponível em conversas diretas ou no protocolo legado.`,executionModelHint:`Modelo-base do runtime autônomo. A política automática de PRD/SPEC ainda pode selecionar um modelo permitido por agente.`,parallelismHint:`Teto de agentes simultâneos. O valor efetivo é o menor limite entre projeto, DAG, provider e squad.`,leaseHint:`Tempo de lease configurado para o coordenador autônomo.`,assuranceToggleHint:`Ativa ou remove os gates de evidência, revisão e qualidade do projeto. Recomenda-se manter ativo.`,assuranceVersionHint:`Versão do contrato de assurance. É fixa e somente leitura.`,assuranceDepthHint:`Auto ajusta o rigor ao escopo; base exige o conjunto padrão; elevated amplia validações para mudanças mais abrangentes.`,finalCommitHint:`Exige que as evidências comprovem o commit final integrado. Sinais de produção ou migração ainda podem exigir isso mesmo quando desativado.`,context:`Contexto`,overview:`Visão geral do projeto`,metricLabels:{agents:`Agentes`,squads:`Squads`,skills:`Skills`,rules:`Rules`,hooks:`Hooks`},areaLabels:{brandbook:`Brandbook`,design_system:`Design System`,software_architecture:`Arquitetura de Software`,growth_strategy:`Estratégia de Growth`,marketing_strategy:`Estratégia de Marketing`,sales_playbook:`Playbook de Sales`},available:`Criado`,artifactUnavailable:`Ainda não criado`,componentGuide:`Preencha cada responsabilidade separadamente. Use a versão exata do software e, para serviços em nuvem ou hospedagem, informe Serviço em nuvem.`,versionHint:`Software: 22.16.0 ou 17.6, sem prefixos (^, ~, >=). Serviço gerenciado: Serviço em nuvem. Hospedagem: Serviço em nuvem.`,referenceHint:`Ex.: npm:hono, docker:node:22.16.0-bookworm-slim, service:supabase ou provider:cloudflare-pages.`,overrides:`Opções avançadas (JSON)`,overridesHint:`Use apenas fatos técnicos transversais confirmados. Deixe vazio quando não houver exceções.`,versions:`Versões detectadas no workspace`,exact:`Verificada`,constraint:`Requisito`,versionUnavailable:`Não encontrada`,runtime:`Runtime do Dashboard`,installed:`Instalado no projeto`,missing:`Ausente no projeto`,bundled:`Empacotado no Dashboard`,current:`Atual`,configured:`Configurado`,health:`Saúde`,dependencies:`Dependências técnicas`,documentation:`Documentação`,unknown:`Desconhecido`,unavailable:`Indisponível`,notApplicable:`Não aplicável`,complete:`Completo`,incomplete:`Incompleto`,incompleteInstallation:`Há dependências técnicas locais ausentes neste computador.`,dismiss:`Fechar aviso`,contextGuide:`O contexto começa pelas fontes canônicas e inclui somente arquivos relevantes para a tarefa. Saídas geradas são consultadas apenas em setup, release ou checagem de paridade.`,contextDomains:`Branding, Marketing, Growth e Sales são usados sob demanda pelos respectivos especialistas, quando houver uma tarefa e artefatos desses domínios. Não os adicione aqui apenas por existirem como capacidades.`},"en-US":{eyebrow:`Settings`,title:`Project settings`,intro:`Edit the central project file with schema validation before writing.`,loading:`Loading…`,loadError:`Project settings could not be loaded.`,retry:`Try again`,back:`Back to dashboard`,save:`Save settings`,saving:`Validating and saving…`,saved:`Settings saved and validated.`,framework:`ZAIP-AIOS framework`,frameworkHint:`Enable or disable the framework for this project.`,identity:`Project identity`,workspacePath:`Project path`,workspacePathHint:`Local folder used by this Dashboard instance.`,workspacePathLoading:`Identifying path…`,workspacePathUnavailable:`Path unavailable`,stack:`Stack and languages`,execution:`Execution`,assurance:`Assurance`,executionToggleHint:`Writes or removes the execution block. Without it, the project uses manual execution.`,runtimeHint:`Managed runs PRDs/SPECs while standalone Tasks stay direct. Manual never starts a provider; autonomous also permits explicitly commanded managed standalone execution.`,providerHint:`Provider that starts autonomous execution agents: Codex or Claude.`,autonomyProviderHint:`Autonomy-v1 requires Codex for managed execution. Claude remains available for direct conversations or the legacy protocol.`,executionModelHint:`Base model for the autonomous runtime. PRD/SPEC automatic policy may still select an allowed model per agent.`,parallelismHint:`Maximum simultaneous agents. Effective parallelism is the smallest project, DAG, provider, and squad limit.`,leaseHint:`Lease duration configured for the autonomous coordinator.`,assuranceToggleHint:`Enables or removes project evidence, review, and quality gates. Keeping it enabled is recommended.`,assuranceVersionHint:`Assurance contract version. It is fixed and read-only.`,assuranceDepthHint:`Auto adapts rigor to scope; base uses the standard set; elevated expands validation for broader changes.`,finalCommitHint:`Requires evidence for the final integrated commit. Production or migration signals may still require it when disabled.`,context:`Context`,overview:`Project overview`,metricLabels:{agents:`Agents`,squads:`Squads`,skills:`Skills`,rules:`Rules`,hooks:`Hooks`},areaLabels:{brandbook:`Brandbook`,design_system:`Design System`,software_architecture:`Software Architecture`,growth_strategy:`Growth Strategy`,marketing_strategy:`Marketing Strategy`,sales_playbook:`Sales Playbook`},available:`Created`,artifactUnavailable:`Not created yet`,componentGuide:`Fill each responsibility separately. Use an exact software version and, for cloud services or hosting, enter Cloud service.`,versionHint:`Software: 22.16.0 or 17.6, without prefixes (^, ~, >=). Managed service: Cloud service. Hosting: Cloud service.`,referenceHint:`E.g. npm:hono, docker:node:22.16.0-bookworm-slim, service:supabase, or provider:cloudflare-pages.`,overrides:`Advanced options (JSON)`,overridesHint:`Use only confirmed cross-cutting technical facts. Leave empty when there are no exceptions.`,versions:`Versions detected in the workspace`,exact:`Verified`,constraint:`Requirement`,versionUnavailable:`Not found`,runtime:`Dashboard runtime`,installed:`Installed in project`,missing:`Missing from project`,bundled:`Bundled in Dashboard`,current:`Current`,configured:`Configured`,health:`Health`,dependencies:`Technical dependencies`,documentation:`Documentation`,unknown:`Unknown`,unavailable:`Unavailable`,notApplicable:`Not applicable`,complete:`Complete`,incomplete:`Incomplete`,incompleteInstallation:`Some local technical dependencies are missing on this computer.`,dismiss:`Dismiss notification`,contextGuide:`Context starts from canonical sources and includes only files relevant to the task. Generated outputs are consulted only for setup, release, or parity checks.`,contextDomains:`Branding, Marketing, Growth, and Sales are used on demand by their respective specialists when there is a task and artifacts in those domains. Do not add them here merely because they exist as capabilities.`}},N=`autonomy-v1`,P=n([`essential`,`balanced`,`persistent`]),F=a({version:r(1),preset:P}).strict(),I=Object.freeze({essential:Object.freeze({label:`Essencial`,attempts:4,replans:1,automatic_astra:!1}),balanced:Object.freeze({label:`Equilibrado`,attempts:10,replans:3,automatic_astra:!0}),persistent:Object.freeze({label:`Persistente — ilimitado`,attempts:null,replans:null,automatic_astra:!0})});function L(e){let t=F.parse(e??{version:1,preset:`balanced`});return Object.freeze({version:N,preset:t.preset,...I[t.preset],repairs_per_replan:3})}function R({value:e,onChange:t,disabled:n=!1,locale:r=`pt-BR`}){let i=(0,s.useId)(),a=L(e),o=r===`pt-BR`;return(0,c.jsxs)(`div`,{children:[!e&&(0,c.jsx)(`p`,{children:o?`Projeto legado: selecione e salve um perfil para adotar os novos controles nas novas Tasks.`:`Legacy project: select and save a preset to adopt the new controls for new Tasks.`}),(0,c.jsxs)(`label`,{className:`project-settings-field`,htmlFor:i,children:[(0,c.jsx)(`strong`,{children:o?`Perfil de autonomia`:`Autonomy preset`}),(0,c.jsx)(`select`,{id:i,"aria-describedby":`${i}-detail`,disabled:n,value:a.preset,onChange:e=>t({version:1,preset:P.parse(e.target.value)}),children:P.options.map(e=>(0,c.jsx)(`option`,{value:e,children:o?I[e].label:{essential:`Essential`,balanced:`Balanced`,persistent:`Persistent — unlimited`}[e]},e))})]}),(0,c.jsx)(`p`,{id:`${i}-detail`,role:`status`,children:a.attempts===null?o?`Sem limite de tentativas ou replanejamentos. Pode continuar indefinidamente e consumir créditos até você cancelar.`:`No attempt or replanning limit. May continue indefinitely and consume credits until you cancel.`:o?`${a.attempts} execuções por Task (1 inicial + ${a.attempts-1} reparações), até ${a.replans} replanejamento(s). Sem abandono por tempo.`:`${a.attempts} executions per Task (1 initial + ${a.attempts-1} repairs), up to ${a.replans} replan(s). No time-based abandonment.`}),(0,c.jsx)(`p`,{children:a.automatic_astra?o?`Replanejamento: Sol/high no primeiro, Astra/high a partir do segundo. Astra/high pode executar a partir do terceiro.`:`Replanning: Sol/high first, Astra/high from the second. Astra/high may execute from the third.`:o?`Nunca usa Astra automaticamente. Exceção: agente principal de tarefa avulsa com Astra selecionado por você no Codex.`:`Never selects Astra automatically. Exception: a standalone principal with Astra manually selected in Codex.`}),(0,c.jsx)(`p`,{children:o?`A mudança vale para novas Tasks; as iniciadas conservam o perfil e o histórico. Tarefas avulsas priorizam execução direta. Ao delegar, a ZAIP informa que modelo e esforço dos subagentes podem mudar. Critérios de aceite e permissões não são reduzidos.`:`Changes apply to new Tasks; started Tasks retain their preset and history. Standalone work prefers direct execution. Delegation discloses that subagent model and effort may differ. Acceptance criteria and permissions are not reduced.`})]})}function z({api:e,locale:t,onClose:n}){let r=M[t],[i,a]=(0,s.useState)(null),[d,f]=(0,s.useState)(null),[p,v]=(0,s.useState)(null),[x,S]=(0,s.useState)(`{}`),[C,w]=(0,s.useState)(!1),[T,k]=(0,s.useState)(!0),[A,N]=(0,s.useState)(null),[P,F]=(0,s.useState)(null),[I,L]=(0,s.useState)(!1),z=o(),B=d===null?null:O(d),H=(0,s.useCallback)(async()=>{k(!0),N(null);try{let[t,n]=await Promise.all([e.projectSettings(),e.projectOverview()]),r=m(t);a(t),f(n),v(h(r.components,n.stack_components)),S(r.otherOverrides)}catch(e){N(e instanceof Error?e.message:String(e))}finally{k(!1)}},[e]);(0,s.useEffect)(()=>{H()},[H]),(0,s.useEffect)(()=>{L(d!==null&&O(d).hasMissingDependencies)},[d]);async function U(t){if(t.preventDefault(),i!==null){w(!0),N(null),F(null);try{let t=await e.saveProjectSettings(g(i,p??m(i).components,x)),n=await e.projectOverview(),o=m(t);a(t),f(n),v(o.components),S(o.otherOverrides),F(r.saved)}catch(e){N(e instanceof Error?e.message:String(e))}finally{w(!1)}}}if(i===null){let e=T&&A===null;return(0,c.jsx)(`main`,{"aria-busy":e,className:`project-settings-state`,children:(0,c.jsxs)(`div`,{"aria-live":e?`polite`:`assertive`,className:`project-settings-state-card`,role:e?`status`:`alert`,children:[e?(0,c.jsx)(`span`,{"aria-hidden":`true`,className:`project-settings-loader`}):null,(0,c.jsx)(`p`,{children:r.eyebrow}),(0,c.jsx)(`h1`,{children:A?r.loadError:r.loading}),A?(0,c.jsx)(`p`,{className:`project-settings-state-error`,children:A}):null,A?(0,c.jsx)(`button`,{onClick:()=>void H(),type:`button`,children:r.retry}):null,(0,c.jsxs)(`button`,{onClick:n,type:`button`,children:[`← `,r.back]})]})})}return(0,c.jsxs)(`main`,{className:`project-settings-page`,children:[(0,c.jsxs)(`form`,{onSubmit:U,children:[(0,c.jsxs)(`header`,{className:`project-settings-header`,children:[(0,c.jsxs)(`div`,{children:[(0,c.jsx)(`p`,{children:r.eyebrow}),(0,c.jsx)(`h1`,{children:r.title}),(0,c.jsx)(`span`,{children:r.intro})]}),(0,c.jsxs)(`button`,{className:`project-settings-back`,onClick:n,type:`button`,children:[`← `,r.back]})]}),A?(0,c.jsx)(`div`,{className:`project-settings-message is-error`,role:`alert`,children:A}):null,P?(0,c.jsx)(`div`,{className:`project-settings-message is-success`,role:`status`,children:P}):null,(0,c.jsxs)(`section`,{className:`project-settings-feature`,children:[(0,c.jsxs)(`div`,{children:[(0,c.jsxs)(`h2`,{children:[r.framework,b(d?.framework_version)?` - ${b(d?.framework_version)}`:``]}),(0,c.jsx)(`p`,{children:r.frameworkHint})]}),(0,c.jsx)(W,{checked:i.zaip?.enabled===!0,label:t===`pt-BR`?`Framework ativo`:`Framework enabled`,onChange:e=>a({...i,zaip:{enabled:e}})})]}),(0,c.jsxs)(`section`,{className:`project-settings-summary`,"aria-label":r.overview,children:[d&&j(d.metrics).map(e=>(0,c.jsxs)(`div`,{className:`project-settings-metric`,children:[(0,c.jsx)(`strong`,{children:e.value}),(0,c.jsx)(`span`,{children:r.metricLabels[e.id]})]},e.id)),B?(0,c.jsx)(V,{installation:B,locale:t}):null]}),(0,c.jsx)(l,{className:`is-wide`,title:r.overview,children:(0,c.jsx)(`div`,{className:`project-overview`,"aria-live":`polite`,children:d?.areas.map(e=>(0,c.jsxs)(`div`,{className:`project-overview-item`,children:[(0,c.jsxs)(`div`,{children:[(0,c.jsx)(`strong`,{children:r.areaLabels[e.id]}),(0,c.jsx)(`code`,{children:e.artifact})]}),(0,c.jsx)(`span`,{className:e.available?`is-available`:`is-unavailable`,children:e.available===!0?r.available:e.available===!1?r.artifactUnavailable:r.unavailable})]},e.id))})}),(0,c.jsx)(l,{className:`is-wide project-detected-versions`,title:r.versions,children:(0,c.jsx)(D,{components:d?.stack_components??[],text:r,showTitle:!1})}),(0,c.jsxs)(`div`,{className:`project-settings-grid`,children:[(0,c.jsxs)(l,{className:`is-wide project-identity-card`,title:r.identity,children:[(0,c.jsx)(u,{className:`project-settings-workspace-field`,hint:r.workspacePathHint,label:r.workspacePath,children:(0,c.jsx)(`code`,{className:`project-settings-workspace-path`,children:z.status?.workspace??(z.unavailable?r.workspacePathUnavailable:r.workspacePathLoading)})}),(0,c.jsx)(u,{label:`Schema`,children:(0,c.jsx)(`input`,{readOnly:!0,value:i.schema_version})}),(0,c.jsx)(u,{label:t===`pt-BR`?`ID do projeto`:`Project ID`,children:(0,c.jsx)(`input`,{required:!0,value:i.project.id,onChange:e=>a({...i,project:{...i.project,id:e.target.value}})})}),(0,c.jsx)(u,{label:t===`pt-BR`?`Nome do projeto`:`Project name`,children:(0,c.jsx)(`input`,{required:!0,value:i.project.name,onChange:e=>a({...i,project:{...i.project,name:e.target.value}})})}),(0,c.jsx)(u,{label:`Timezone IANA`,children:(0,c.jsx)(`input`,{required:!0,value:i.project.timezone,onChange:e=>a({...i,project:{...i.project,timezone:e.target.value}})})})]}),(0,c.jsxs)(l,{className:`is-wide`,title:r.stack,children:[(0,c.jsx)(`p`,{className:`project-stack-guide`,children:r.componentGuide}),p?(0,c.jsx)(E,{components:p,locale:t,onChange:v,referenceHint:r.referenceHint,versionHint:r.versionHint}):null,(0,c.jsxs)(`details`,{className:`project-settings-advanced`,children:[(0,c.jsx)(`summary`,{children:r.overrides}),(0,c.jsx)(u,{hint:r.overridesHint,label:`Overrides`,children:(0,c.jsx)(`textarea`,{rows:7,value:x,onChange:e=>S(e.target.value)})})]})]}),(0,c.jsxs)(l,{title:r.execution,children:[(0,c.jsx)(G,{checked:i.execution!==void 0,hint:r.executionToggleHint,label:t===`pt-BR`?`Incluir configuração de execução`:`Include execution configuration`,onChange:e=>a({...i,execution:e?{runtime:`codex_native`}:void 0})}),i.execution?(0,c.jsxs)(c.Fragment,{children:[(0,c.jsx)(u,{hint:r.runtimeHint,label:`Runtime`,children:(0,c.jsxs)(`select`,{value:i.execution.runtime,"aria-label":`Runtime`,onChange:e=>a({...i,execution:y(e.target.value)}),children:[(0,c.jsx)(`option`,{value:`manual`,children:`manual`}),(0,c.jsx)(`option`,{value:`codex_native`,children:`codex_native (Codex)`}),(0,c.jsx)(`option`,{value:`managed`,children:`managed (PRD/SPEC)`}),(0,c.jsx)(`option`,{value:`autonomous`,children:`autonomous`})]})}),i.execution.runtime!==`manual`&&i.execution.runtime!==`codex_native`?(0,c.jsx)(K,{config:i,setConfig:a,text:r}):null]}):null]}),(0,c.jsx)(l,{title:t===`pt-BR`?`Autonomia e recuperação`:`Autonomy and recovery`,children:(0,c.jsx)(R,{value:i.autonomy,disabled:C,locale:t,onChange:e=>a({...i,autonomy:e})})}),(0,c.jsxs)(l,{title:r.assurance,children:[(0,c.jsx)(G,{checked:i.assurance!==void 0,hint:r.assuranceToggleHint,label:t===`pt-BR`?`Incluir assurance`:`Include assurance`,onChange:e=>a({...i,assurance:e?{version:1,standard_depth:`auto`,require_final_commit:!0}:void 0})}),i.assurance?(0,c.jsxs)(c.Fragment,{children:[(0,c.jsx)(u,{hint:r.assuranceVersionHint,label:t===`pt-BR`?`Versão`:`Version`,children:(0,c.jsx)(`input`,{readOnly:!0,value:i.assurance.version})}),(0,c.jsx)(u,{hint:r.assuranceDepthHint,label:t===`pt-BR`?`Profundidade padrão`:`Standard depth`,children:(0,c.jsxs)(`select`,{value:i.assurance.standard_depth,onChange:e=>a({...i,assurance:{...i.assurance??{version:1,standard_depth:`auto`,require_final_commit:!0},standard_depth:e.target.value}}),children:[(0,c.jsx)(`option`,{value:`auto`,children:`auto`}),(0,c.jsx)(`option`,{value:`base`,children:`base`}),(0,c.jsx)(`option`,{value:`elevated`,children:`elevated`})]})}),(0,c.jsx)(W,{checked:i.assurance.require_final_commit,hint:r.finalCommitHint,label:t===`pt-BR`?`Exigir commit final`:`Require final commit`,onChange:e=>a({...i,assurance:{...i.assurance??{version:1,standard_depth:`auto`,require_final_commit:!0},require_final_commit:e}})})]}):null]}),(0,c.jsxs)(l,{className:`is-wide`,title:r.context,children:[(0,c.jsx)(G,{checked:i.context!==void 0,label:t===`pt-BR`?`Incluir raízes de contexto`:`Include context roots`,onChange:e=>a({...i,context:e?{canonical_roots:[`packages`],projection_roots:[]}:void 0})}),i.context?(0,c.jsxs)(c.Fragment,{children:[(0,c.jsxs)(`div`,{className:`project-settings-guidance`,children:[(0,c.jsx)(`p`,{children:r.contextGuide}),(0,c.jsx)(`p`,{children:r.contextDomains})]}),(0,c.jsxs)(`div`,{className:`project-settings-fields two-columns`,children:[(0,c.jsx)(u,{hint:t===`pt-BR`?`Uma pasta por linha. Estas são as fontes principais do projeto.`:`One folder per line. These are the project's primary sources.`,label:t===`pt-BR`?`Fontes canônicas`:`Canonical sources`,children:(0,c.jsx)(`textarea`,{required:!0,rows:5,value:i.context.canonical_roots.join(`
+`),onChange:e=>a({...i,context:{...i.context??{canonical_roots:[`packages`],projection_roots:[]},canonical_roots:_(e.target.value)}})})}),(0,c.jsx)(u,{hint:t===`pt-BR`?`Uma pasta por linha. São saídas geradas, não fontes de contexto normal.`:`One folder per line. These are generated outputs, not normal context sources.`,label:t===`pt-BR`?`Saídas geradas/publicadas`:`Generated/published outputs`,children:(0,c.jsx)(`textarea`,{rows:5,value:i.context.projection_roots.join(`
+`),onChange:e=>a({...i,context:{...i.context??{canonical_roots:[`packages`],projection_roots:[]},projection_roots:_(e.target.value)}})})})]})]}):null]})]}),(0,c.jsxs)(`footer`,{className:`project-settings-footer`,children:[(0,c.jsx)(`span`,{children:`.agents/config/project.yaml`}),(0,c.jsx)(`button`,{disabled:C,type:`submit`,children:C?r.saving:r.save})]})]}),I&&B?.hasMissingDependencies?(0,c.jsxs)(`div`,{"aria-live":`assertive`,className:`project-installation-toast`,role:`alert`,children:[(0,c.jsx)(`span`,{children:r.incompleteInstallation}),(0,c.jsx)(`button`,{"aria-label":r.dismiss,onClick:()=>L(!1),type:`button`,children:`×`})]}):null]})}function B(e,t){return`${new Intl.NumberFormat(t,{maximumFractionDigits:2}).format(e)}%`}function V({installation:e,locale:t}){let n=M[t];return(0,c.jsxs)(c.Fragment,{children:[(0,c.jsxs)(`p`,{className:`project-installation-health`,children:[n.health,`:`,` `,e.health.state===`healthy`?t===`pt-BR`?`Saudável`:`Healthy`:e.health.state===`degraded`?t===`pt-BR`?`Degradada`:`Degraded`:n.unknown]}),(0,c.jsx)(H,{dimension:e.dependencies,label:n.dependencies,locale:t}),(0,c.jsx)(H,{dimension:e.documentation,label:n.documentation,locale:t})]})}function H({dimension:e,label:t,locale:n}){let r=M[n],i=e.state===`not_applicable`?r.notApplicable:e.percentage===null?r.unknown:B(e.percentage,n),a=U(e.state,n);return(0,c.jsxs)(`div`,{className:`project-settings-metric installation-metric is-${e.state}`,children:[(0,c.jsx)(`strong`,{children:i}),(0,c.jsx)(`span`,{children:e.total===null||e.completed===null?t:`${t} · ${e.completed}/${e.total}`}),(0,c.jsx)(`small`,{children:a})]})}function U(e,t){let n=M[t];return e===`complete`?n.complete:e===`incomplete`?n.incomplete:e===`not_applicable`?n.notApplicable:e===`unavailable`?n.unavailable:n.unknown}function W({checked:e,hint:t,label:n,onChange:r}){return(0,c.jsxs)(`div`,{className:`project-settings-toggle-field`,children:[(0,c.jsxs)(`label`,{className:`project-settings-toggle`,children:[(0,c.jsx)(`input`,{checked:e,onChange:e=>r(e.target.checked),type:`checkbox`}),(0,c.jsx)(`span`,{"aria-hidden":`true`}),(0,c.jsx)(`strong`,{children:n})]}),t?(0,c.jsx)(`small`,{children:t}):null]})}function G(e){return(0,c.jsx)(W,{...e})}function K({config:e,setConfig:t,text:n}){let r=e.execution&&e.execution.runtime!==`manual`&&e.execution.runtime!==`codex_native`?e.execution:v(),i=n=>t({...e,execution:{runtime:r.runtime,autonomous:n}});return(0,c.jsxs)(c.Fragment,{children:[(0,c.jsx)(u,{hint:e.autonomy?.version===1?n.autonomyProviderHint:n.providerHint,label:`Provider`,children:(0,c.jsxs)(`select`,{value:r.autonomous.provider,"aria-label":`Provider`,onChange:e=>i({...r.autonomous,provider:e.target.value}),children:[(0,c.jsx)(`option`,{value:`codex`,children:`codex`}),(0,c.jsx)(`option`,{value:`claude`,disabled:e.autonomy?.version===1,children:`claude`})]})}),(0,c.jsx)(u,{hint:n.executionModelHint,label:`Model`,children:(0,c.jsx)(`input`,{required:!0,value:r.autonomous.model,onChange:e=>i({...r.autonomous,model:e.target.value})})}),(0,c.jsx)(u,{hint:n.parallelismHint,label:`Max parallelism`,children:(0,c.jsx)(`input`,{max:8,min:1,type:`number`,value:r.autonomous.max_parallelism,onChange:e=>i({...r.autonomous,max_parallelism:Number(e.target.value)})})}),(0,c.jsx)(u,{hint:n.leaseHint,label:`Lease (ms)`,children:(0,c.jsx)(`input`,{max:36e5,min:5e3,step:1e3,type:`number`,value:r.autonomous.lease_ms,onChange:e=>i({...r.autonomous,lease_ms:Number(e.target.value)})})})]})}export{z as ProjectSettingsPage};

package/templates/.agents/dashboard/apps/frontend/dist/assets/{TraceabilityWorkspace-B-5yP5Jx.js → TraceabilityWorkspace-BN8FwP5S.js}

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-B0Jwz_rk.js";import{n as r}from"./traceability-DFpwb0TN.js";import{n as i}from"./index-CPcBwWeO.js";var a=e(t(),1),o=n();function s(e,t){let n=t.trim().toLocaleLowerCase();return n===``?[...e]:e.filter(e=>`${e.title} ${e.id}`.toLocaleLowerCase().includes(n))}function c(e,t,n){return n?[...e]:s(e,t)}function l(e){return`traceability-task-option-${e}`}function u({locale:e,loadingTaskId:t,hasMoreTasks:n,isLoadingTasks:s,onLoadMoreTasks:u,onSelectTask:d,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,selectedTaskId:h,tasks:g,trace:_}){let v=[...g].sort((e,t)=>Date.parse(t.created_at)-Date.parse(e.created_at)),y=v.find(e=>e.id===h),[b,x]=(0,a.useState)(()=>y?.title??h),[S,C]=(0,a.useState)(!1),[w,T]=(0,a.useState)(!1),[E,D]=(0,a.useState)(0),[O,k]=(0,a.useState)(12),A=(0,a.useMemo)(()=>c(v,b,w),[b,w,v]),j=A.slice(0,O),M=j.length<A.length,N=`traceability-task-search`,P=`traceability-task-results`,F=e===`pt-BR`?`Task selecionada`:`Selected task`,I=e===`pt-BR`?`Buscar task por nome ou ID`:`Search task by name or ID`,L=S?A[E]?.id:void 0;(0,a.useEffect)(()=>{x(y?.title??h),D(0)},[y?.title,h]);let R=e=>{x(e.title),C(!1),T(!1),d(e.id)},z=(e=!0)=>{C(!0),T(!0),e&&(D(0),k(12))};return(0,o.jsxs)(`section`,{className:`traceability-workspace`,children:[(0,o.jsxs)(`header`,{children:[(0,o.jsxs)(`div`,{children:[(0,o.jsx)(`label`,{htmlFor:N,children:F}),(0,o.jsx)(`input`,{"aria-activedescendant":L===void 0?void 0:l(L),"aria-autocomplete":`list`,"aria-controls":P,"aria-expanded":S,"aria-label":I,id:N,onChange:e=>{x(e.target.value),D(0),T(!1),k(12),C(!0)},onClick:()=>z(),onFocus:()=>z(),onKeyDown:e=>{if(e.key===`ArrowDown`)e.preventDefault(),z(!1),D(e=>Math.min(e+1,Math.max(0,v.length-1)));else if(e.key===`ArrowUp`)e.preventDefault(),z(!1),D(e=>Math.max(0,e-1));else if(e.key===`Enter`&&S){let t=A[E];t!==void 0&&(e.preventDefault(),R(t))}else e.key===`Escape`&&C(!1)},role:`combobox`,type:`search`,value:b}),S?(0,o.jsx)(`div`,{"aria-label":I,className:`traceability-task-results`,id:P,onScroll:e=>{let{clientHeight:t,scrollHeight:r,scrollTop:a}=e.currentTarget;a+t<r-32||(n&&u(),j.length<A.length&&k(e=>i(e,A.length,12)))},role:`listbox`,children:A.length>0?j.map((e,t)=>(0,o.jsx)(`div`,{role:`presentation`,children:(0,o.jsx)(`button`,{"aria-selected":e.id===h,className:t===E?`is-active`:void 0,id:l(e.id),onClick:()=>R(e),role:`option`,type:`button`,children:(0,o.jsx)(`strong`,{children:e.title})})},e.id)):(0,o.jsx)(`div`,{className:`traceability-task-no-results`,role:`status`,children:e===`pt-BR`?`Nenhuma task encontrada.`:`No tasks found.`})}):null,S&&A.length>0?(0,o.jsx)(`p`,{"aria-live":`polite`,className:`traceability-task-pagination-status`,role:`status`,children:s?e===`pt-BR`?`Carregando mais tasks…`:`Loading more tasks…`:M||n?e===`pt-BR`?`${j.length} de ${A.length} tasks exibidas. Role para carregar mais.`:`${j.length} of ${A.length} tasks shown. Scroll to load more.`:e===`pt-BR`?`${A.length} tasks exibidas. Fim da lista.`:`${A.length} tasks shown. End of list.`}):null]}),(0,o.jsx)(`small`,{children:e===`pt-BR`?`Selecione pelo nome para visualizar o ciclo completo sem precisar do ID.`:`Select by name to inspect the complete lifecycle without knowing the ID.`})]}),t?(0,o.jsx)(`div`,{"aria-live":`polite`,className:`traceability-workspace-loading`,children:e===`pt-BR`?`Carregando as 6 etapas…`:`Loading all 6 stages…`}):_?(0,o.jsx)(r,{embedded:!0,locale:e,onClose:()=>void 0,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,trace:_}):(0,o.jsx)(`p`,{children:e===`pt-BR`?`Nenhuma task disponível.`:`No task available.`})]})}export{u as TraceabilityWorkspace};
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-YfoKMzCQ.js";import{n as r}from"./traceability-Boz50W9b.js";import{n as i}from"./index-uIVtG2ZR.js";var a=e(t(),1),o=n();function s(e,t){let n=t.trim().toLocaleLowerCase();return n===``?[...e]:e.filter(e=>`${e.title} ${e.id}`.toLocaleLowerCase().includes(n))}function c(e,t,n){return n?[...e]:s(e,t)}function l(e){return`traceability-task-option-${e}`}function u({locale:e,loadingTaskId:t,hasMoreTasks:n,isLoadingTasks:s,onLoadMoreTasks:u,onSelectTask:d,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,selectedTaskId:h,tasks:g,trace:_}){let v=[...g].sort((e,t)=>Date.parse(t.created_at)-Date.parse(e.created_at)),y=v.find(e=>e.id===h),[b,x]=(0,a.useState)(()=>y?.title??h),[S,C]=(0,a.useState)(!1),[w,T]=(0,a.useState)(!1),[E,D]=(0,a.useState)(0),[O,k]=(0,a.useState)(12),A=(0,a.useMemo)(()=>c(v,b,w),[b,w,v]),j=A.slice(0,O),M=j.length<A.length,N=`traceability-task-search`,P=`traceability-task-results`,F=e===`pt-BR`?`Task selecionada`:`Selected task`,I=e===`pt-BR`?`Buscar task por nome ou ID`:`Search task by name or ID`,L=S?A[E]?.id:void 0;(0,a.useEffect)(()=>{x(y?.title??h),D(0)},[y?.title,h]);let R=e=>{x(e.title),C(!1),T(!1),d(e.id)},z=(e=!0)=>{C(!0),T(!0),e&&(D(0),k(12))};return(0,o.jsxs)(`section`,{className:`traceability-workspace`,children:[(0,o.jsxs)(`header`,{children:[(0,o.jsxs)(`div`,{children:[(0,o.jsx)(`label`,{htmlFor:N,children:F}),(0,o.jsx)(`input`,{"aria-activedescendant":L===void 0?void 0:l(L),"aria-autocomplete":`list`,"aria-controls":P,"aria-expanded":S,"aria-label":I,id:N,onChange:e=>{x(e.target.value),D(0),T(!1),k(12),C(!0)},onClick:()=>z(),onFocus:()=>z(),onKeyDown:e=>{if(e.key===`ArrowDown`)e.preventDefault(),z(!1),D(e=>Math.min(e+1,Math.max(0,v.length-1)));else if(e.key===`ArrowUp`)e.preventDefault(),z(!1),D(e=>Math.max(0,e-1));else if(e.key===`Enter`&&S){let t=A[E];t!==void 0&&(e.preventDefault(),R(t))}else e.key===`Escape`&&C(!1)},role:`combobox`,type:`search`,value:b}),S?(0,o.jsx)(`div`,{"aria-label":I,className:`traceability-task-results`,id:P,onScroll:e=>{let{clientHeight:t,scrollHeight:r,scrollTop:a}=e.currentTarget;a+t<r-32||(n&&u(),j.length<A.length&&k(e=>i(e,A.length,12)))},role:`listbox`,children:A.length>0?j.map((e,t)=>(0,o.jsx)(`div`,{role:`presentation`,children:(0,o.jsx)(`button`,{"aria-selected":e.id===h,className:t===E?`is-active`:void 0,id:l(e.id),onClick:()=>R(e),role:`option`,type:`button`,children:(0,o.jsx)(`strong`,{children:e.title})})},e.id)):(0,o.jsx)(`div`,{className:`traceability-task-no-results`,role:`status`,children:e===`pt-BR`?`Nenhuma task encontrada.`:`No tasks found.`})}):null,S&&A.length>0?(0,o.jsx)(`p`,{"aria-live":`polite`,className:`traceability-task-pagination-status`,role:`status`,children:s?e===`pt-BR`?`Carregando mais tasks…`:`Loading more tasks…`:M||n?e===`pt-BR`?`${j.length} de ${A.length} tasks exibidas. Role para carregar mais.`:`${j.length} of ${A.length} tasks shown. Scroll to load more.`:e===`pt-BR`?`${A.length} tasks exibidas. Fim da lista.`:`${A.length} tasks shown. End of list.`}):null]}),(0,o.jsx)(`small`,{children:e===`pt-BR`?`Selecione pelo nome para visualizar o ciclo completo sem precisar do ID.`:`Select by name to inspect the complete lifecycle without knowing the ID.`})]}),t?(0,o.jsx)(`div`,{"aria-live":`polite`,className:`traceability-workspace-loading`,children:e===`pt-BR`?`Carregando as 6 etapas…`:`Loading all 6 stages…`}):_?(0,o.jsx)(r,{embedded:!0,locale:e,onClose:()=>void 0,onOpenChange:f,onOpenPrd:p,onOpenSpec:m,trace:_}):(0,o.jsx)(`p`,{children:e===`pt-BR`?`Nenhuma task disponível.`:`No task available.`})]})}export{u as TraceabilityWorkspace};