@zaip-ai/cli 4.4.0 → 4.6.0

package/templates/.agents/dashboard/README.md

@@ -1,5 +1,7 @@
 # Dashboard ZAIP-AIOS SQLite
 
+Logs de abertura e reconciliação: [diagnóstico local](packages/local-runtime/DIAGNOSTICS.md).
+
 `.local/sqlite/` centraliza os bancos SQLite locais do workspace. A pasta pode conter vários
 arquivos, com um nome estável para cada finalidade, conforme a
 [regra de armazenamento local](../rules/local-sqlite-storage.md).

package/templates/.agents/dashboard/apps/frontend/dist/assets/{CostCalculationGuidePage-f4ZGJRg3.js → CostCalculationGuidePage-BRtiPijr.js}

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-D7PrDZy9.js";var r=e(t(),1),i=n(),a={input:1e5,cache:4e4,output:2e4,reasoning:8e3},o=e=>Math.round(e*1e6)/1e6;function s(e,t,n,r,i){let a=o(Math.max(e.input-e.cache,0)/1e6*t.input*n),s=o(e.cache/1e6*(t.cache??0)*n),c=o(e.output/1e6*t.output*r),l=o(a+s+c);return{usage:e,rates:t,inputMultiplier:n,outputMultiplier:r,inputUsd:a,cacheUsd:s,outputUsd:c,reasoningUsd:0,totalUsd:l,totalBrl:i===null?null:o(l*i)}}function c(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 l(e,t,n){let r=c(e,t);return r===null?null:s(a,r,1,1,n)}function u(e,t){return e.long_context_threshold_tokens===null?null:s({input:e.long_context_threshold_tokens+5e4,cache:a.cache,output:a.output,reasoning:a.reasoning},c(e,`standard`),e.long_context_input_multiplier,e.long_context_output_multiplier,t)}var d={"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 f(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 p(e,t,n,r,i){return e==null?i:f(e,t,n,r)}function m(e,t){return new Intl.NumberFormat(t).format(e)}function h({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:`${m(e.usage.input,r)} − ${m(e.usage.cache,r)} = ${m(s,r)} tokens`,cost:null},{label:a.input,operation:`${m(s,r)} ÷ 1M × ${p(e.rates.input,t,n,o,a.noPublishedRate)}${c}`,cost:e.inputUsd},{label:a.cache,operation:`${m(e.usage.cache,r)} ÷ 1M × ${p(u,t,n,o,a.noPublishedRate)}${c}`,cost:e.cacheUsd},{label:a.output,operation:`${m(e.usage.output,r)} ÷ 1M × ${p(e.rates.output,t,n,o,a.noPublishedRate)}${l}`,cost:e.outputUsd},{label:a.reasoning,operation:`${m(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?`—`:f(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:f(e.totalUsd,t,n,o)})]})]})}function g({catalog:e,fxRate:t,locale:n,onClose:a}){let o=d[n],[s,c]=(0,r.useState)(e.models[0]?.id??``),[f,g]=(0,r.useState)(`USD`),_=(0,r.useMemo)(()=>e.models.find(e=>e.id===s)??e.models[0]??null,[e.models,s]);if(_===null)return(0,i.jsxs)(`main`,{className:`cost-guide`,children:[(0,i.jsxs)(`button`,{onClick:a,type:`button`,children:[`← `,o.back]}),(0,i.jsx)(`h1`,{children:o.title}),(0,i.jsx)(`p`,{children:o.unavailable})]});let v=t?.rate??null,y=l(_,`standard`,v),b=l(_,`priority`,v),x=u(_,v),S=b!==null&&y.totalUsd>0?b.totalUsd/y.totalUsd:null,C=[{label:o.input,standard:_.input_per_million_usd,priority:_.priority_input_per_million_usd},{label:o.cache,standard:_.cached_input_per_million_usd,priority:_.priority_cached_input_per_million_usd},{label:o.output,standard:_.output_per_million_usd,priority:_.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:o.eyebrow}),(0,i.jsx)(`h1`,{children:o.title}),(0,i.jsx)(`p`,{children:o.intro})]}),(0,i.jsxs)(`button`,{onClick:a,type:`button`,children:[`← `,o.back]})]}),(0,i.jsxs)(`section`,{className:`cost-guide-controls`,"aria-label":o.model,children:[(0,i.jsxs)(`label`,{children:[o.model,(0,i.jsx)(`select`,{value:_.id,onChange:e=>c(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:[o.currency,(0,i.jsxs)(`select`,{value:f,onChange:e=>g(e.target.value),children:[(0,i.jsx)(`option`,{value:`USD`,children:`USD`}),(0,i.jsxs)(`option`,{value:`BRL`,children:[`BRL `,v===null?`(${o.unavailable})`:`(1 USD = ${v.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:o.rateTitle}),(0,i.jsx)(`p`,{children:o.rateIntro})]}),(0,i.jsx)(`div`,{className:`cost-guide-table-wrap`,children:(0,i.jsxs)(`table`,{children:[(0,i.jsxs)(`caption`,{children:[_.id,` · `,o.millionRate]}),(0,i.jsx)(`thead`,{children:(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`col`}),(0,i.jsx)(`th`,{scope:`col`,children:o.standard}),(0,i.jsx)(`th`,{scope:`col`,children:o.priority}),(0,i.jsx)(`th`,{scope:`col`,children:o.ratio})]})}),(0,i.jsxs)(`tbody`,{children:[C.map(e=>(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`row`,children:e.label}),(0,i.jsx)(`td`,{children:p(e.standard,f,v,o.unavailable,o.noPublishedRate)}),(0,i.jsx)(`td`,{children:p(e.priority,f,v,o.unavailable,o.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)}×`:o.unavailable})]},e.label)),(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`row`,children:o.reasoning}),(0,i.jsx)(`td`,{colSpan:3,children:o.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:o.conceptsTitle})}),(0,i.jsx)(`div`,{className:`cost-guide-blocks`,children:o.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:o.exampleTitle}),(0,i.jsx)(`p`,{children:o.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:o.standard}),(0,i.jsx)(h,{example:y,currency:f,fxRate:v,locale:n,labels:o})]}),(0,i.jsxs)(`article`,{className:`cost-guide-example-card`,children:[(0,i.jsx)(`h3`,{children:o.priority}),b===null?(0,i.jsx)(`p`,{className:`cost-guide-unavailable`,children:o.unavailable}):(0,i.jsx)(h,{example:b,currency:f,fxRate:v,locale:n,labels:o})]})]}),(0,i.jsxs)(`div`,{className:`cost-guide-speed`,children:[(0,i.jsx)(`span`,{children:o.speedMultiplier}),(0,i.jsx)(`strong`,{children:S===null?o.unavailable:`${S.toFixed(2)}×`}),(0,i.jsxs)(`code`,{children:[o.priority,` `,o.total,` ÷ `,o.standard,` `,o.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:o.longTitle}),(0,i.jsx)(`p`,{children:o.longIntro})]}),(0,i.jsxs)(`div`,{className:`cost-guide-context-summary`,children:[(0,i.jsxs)(`span`,{children:[o.threshold,`:`,` `,(0,i.jsx)(`strong`,{children:_.long_context_threshold_tokens===null?o.unavailable:m(_.long_context_threshold_tokens,n)})]}),(0,i.jsxs)(`span`,{children:[o.longInput,`:`,` `,(0,i.jsx)(`strong`,{children:x===null?o.unavailable:m(x.usage.input,n)})]}),(0,i.jsxs)(`span`,{children:[`Input/cache: `,(0,i.jsxs)(`strong`,{children:[_.long_context_input_multiplier,`×`]})]}),(0,i.jsxs)(`span`,{children:[`Output: `,(0,i.jsxs)(`strong`,{children:[_.long_context_output_multiplier,`×`]})]})]}),x===null?(0,i.jsx)(`p`,{className:`cost-guide-unavailable`,children:o.unavailable}):(0,i.jsx)(h,{example:x,currency:f,fxRate:v,locale:n,labels:o}),(0,i.jsxs)(`div`,{className:`cost-guide-unavailable-combination`,children:[(0,i.jsxs)(`strong`,{children:[o.priorityLong,`: `,o.unavailable]}),(0,i.jsx)(`p`,{children:o.priorityLongNote})]})]}),(0,i.jsx)(`aside`,{className:`cost-guide-final-note`,children:o.finalNote})]})}export{g as CostCalculationGuidePage};
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-fTQhSL85.js";var r=e(t(),1),i=n(),a={input:1e5,cache:4e4,output:2e4,reasoning:8e3},o=e=>Math.round(e*1e6)/1e6;function s(e,t,n,r,i){let a=o(Math.max(e.input-e.cache,0)/1e6*t.input*n),s=o(e.cache/1e6*(t.cache??0)*n),c=o(e.output/1e6*t.output*r),l=o(a+s+c);return{usage:e,rates:t,inputMultiplier:n,outputMultiplier:r,inputUsd:a,cacheUsd:s,outputUsd:c,reasoningUsd:0,totalUsd:l,totalBrl:i===null?null:o(l*i)}}function c(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 l(e,t,n){let r=c(e,t);return r===null?null:s(a,r,1,1,n)}function u(e,t){return e.long_context_threshold_tokens===null?null:s({input:e.long_context_threshold_tokens+5e4,cache:a.cache,output:a.output,reasoning:a.reasoning},c(e,`standard`),e.long_context_input_multiplier,e.long_context_output_multiplier,t)}var d={"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 f(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 p(e,t,n,r,i){return e==null?i:f(e,t,n,r)}function m(e,t){return new Intl.NumberFormat(t).format(e)}function h({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:`${m(e.usage.input,r)} − ${m(e.usage.cache,r)} = ${m(s,r)} tokens`,cost:null},{label:a.input,operation:`${m(s,r)} ÷ 1M × ${p(e.rates.input,t,n,o,a.noPublishedRate)}${c}`,cost:e.inputUsd},{label:a.cache,operation:`${m(e.usage.cache,r)} ÷ 1M × ${p(u,t,n,o,a.noPublishedRate)}${c}`,cost:e.cacheUsd},{label:a.output,operation:`${m(e.usage.output,r)} ÷ 1M × ${p(e.rates.output,t,n,o,a.noPublishedRate)}${l}`,cost:e.outputUsd},{label:a.reasoning,operation:`${m(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?`—`:f(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:f(e.totalUsd,t,n,o)})]})]})}function g({catalog:e,fxRate:t,locale:n,onClose:a}){let o=d[n],[s,c]=(0,r.useState)(e.models[0]?.id??``),[f,g]=(0,r.useState)(`USD`),_=(0,r.useMemo)(()=>e.models.find(e=>e.id===s)??e.models[0]??null,[e.models,s]);if(_===null)return(0,i.jsxs)(`main`,{className:`cost-guide`,children:[(0,i.jsxs)(`button`,{onClick:a,type:`button`,children:[`← `,o.back]}),(0,i.jsx)(`h1`,{children:o.title}),(0,i.jsx)(`p`,{children:o.unavailable})]});let v=t?.rate??null,y=l(_,`standard`,v),b=l(_,`priority`,v),x=u(_,v),S=b!==null&&y.totalUsd>0?b.totalUsd/y.totalUsd:null,C=[{label:o.input,standard:_.input_per_million_usd,priority:_.priority_input_per_million_usd},{label:o.cache,standard:_.cached_input_per_million_usd,priority:_.priority_cached_input_per_million_usd},{label:o.output,standard:_.output_per_million_usd,priority:_.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:o.eyebrow}),(0,i.jsx)(`h1`,{children:o.title}),(0,i.jsx)(`p`,{children:o.intro})]}),(0,i.jsxs)(`button`,{onClick:a,type:`button`,children:[`← `,o.back]})]}),(0,i.jsxs)(`section`,{className:`cost-guide-controls`,"aria-label":o.model,children:[(0,i.jsxs)(`label`,{children:[o.model,(0,i.jsx)(`select`,{value:_.id,onChange:e=>c(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:[o.currency,(0,i.jsxs)(`select`,{value:f,onChange:e=>g(e.target.value),children:[(0,i.jsx)(`option`,{value:`USD`,children:`USD`}),(0,i.jsxs)(`option`,{value:`BRL`,children:[`BRL `,v===null?`(${o.unavailable})`:`(1 USD = ${v.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:o.rateTitle}),(0,i.jsx)(`p`,{children:o.rateIntro})]}),(0,i.jsx)(`div`,{className:`cost-guide-table-wrap`,children:(0,i.jsxs)(`table`,{children:[(0,i.jsxs)(`caption`,{children:[_.id,` · `,o.millionRate]}),(0,i.jsx)(`thead`,{children:(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`col`}),(0,i.jsx)(`th`,{scope:`col`,children:o.standard}),(0,i.jsx)(`th`,{scope:`col`,children:o.priority}),(0,i.jsx)(`th`,{scope:`col`,children:o.ratio})]})}),(0,i.jsxs)(`tbody`,{children:[C.map(e=>(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`row`,children:e.label}),(0,i.jsx)(`td`,{children:p(e.standard,f,v,o.unavailable,o.noPublishedRate)}),(0,i.jsx)(`td`,{children:p(e.priority,f,v,o.unavailable,o.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)}×`:o.unavailable})]},e.label)),(0,i.jsxs)(`tr`,{children:[(0,i.jsx)(`th`,{scope:`row`,children:o.reasoning}),(0,i.jsx)(`td`,{colSpan:3,children:o.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:o.conceptsTitle})}),(0,i.jsx)(`div`,{className:`cost-guide-blocks`,children:o.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:o.exampleTitle}),(0,i.jsx)(`p`,{children:o.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:o.standard}),(0,i.jsx)(h,{example:y,currency:f,fxRate:v,locale:n,labels:o})]}),(0,i.jsxs)(`article`,{className:`cost-guide-example-card`,children:[(0,i.jsx)(`h3`,{children:o.priority}),b===null?(0,i.jsx)(`p`,{className:`cost-guide-unavailable`,children:o.unavailable}):(0,i.jsx)(h,{example:b,currency:f,fxRate:v,locale:n,labels:o})]})]}),(0,i.jsxs)(`div`,{className:`cost-guide-speed`,children:[(0,i.jsx)(`span`,{children:o.speedMultiplier}),(0,i.jsx)(`strong`,{children:S===null?o.unavailable:`${S.toFixed(2)}×`}),(0,i.jsxs)(`code`,{children:[o.priority,` `,o.total,` ÷ `,o.standard,` `,o.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:o.longTitle}),(0,i.jsx)(`p`,{children:o.longIntro})]}),(0,i.jsxs)(`div`,{className:`cost-guide-context-summary`,children:[(0,i.jsxs)(`span`,{children:[o.threshold,`:`,` `,(0,i.jsx)(`strong`,{children:_.long_context_threshold_tokens===null?o.unavailable:m(_.long_context_threshold_tokens,n)})]}),(0,i.jsxs)(`span`,{children:[o.longInput,`:`,` `,(0,i.jsx)(`strong`,{children:x===null?o.unavailable:m(x.usage.input,n)})]}),(0,i.jsxs)(`span`,{children:[`Input/cache: `,(0,i.jsxs)(`strong`,{children:[_.long_context_input_multiplier,`×`]})]}),(0,i.jsxs)(`span`,{children:[`Output: `,(0,i.jsxs)(`strong`,{children:[_.long_context_output_multiplier,`×`]})]})]}),x===null?(0,i.jsx)(`p`,{className:`cost-guide-unavailable`,children:o.unavailable}):(0,i.jsx)(h,{example:x,currency:f,fxRate:v,locale:n,labels:o}),(0,i.jsxs)(`div`,{className:`cost-guide-unavailable-combination`,children:[(0,i.jsxs)(`strong`,{children:[o.priorityLong,`: `,o.unavailable]}),(0,i.jsx)(`p`,{children:o.priorityLongNote})]})]}),(0,i.jsx)(`aside`,{className:`cost-guide-final-note`,children:o.finalNote})]})}export{g as CostCalculationGuidePage};

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

@@ -1,4 +1,4 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-D7PrDZy9.js";import{t as r}from"./dashboard-localization-CF7B1Hjn.js";var i=`# Primeiros passos
+import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-fTQhSL85.js";import{t as r}from"./dashboard-localization-CF7B1Hjn.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.
@@ -62,6 +62,12 @@ velocidade \`standard\`; Fast manual não é herdado pelo fluxo gerenciado.
 Equilibrado 10/3, Persistente ilimitado (execuções/replanejamentos).
 No Equilibrado, os planos novos usam Sol → Sol → Astra. Reiniciar, retomar ou mudar o YAML não zera a quota. \`attempt_count\` do lifecycle
 e reservas de execução do diário não são o mesmo contador.
+
+## Checkout de Task avulsa e release
+
+Uma Task avulsa usa o checkout compartilhado com um único escritor para o repositório inteiro, inclusive entre chats e worktrees. Antes da primeira edição de produto, o responsável registra a posse com \`zaip task workspace TASK-ID --run RUN-ID\`. O retorno esperado é \`mode: shared\` e \`branch: null\`; editar sem posse falha fechado. Mensagens entre chats coordenam, mas o registro central de Task/Run/posse decide quem escreve. Ao transferir a posse, alterações de produto ainda misturadas no checkout bloqueiam a transferência até atribuição e reconciliação.
+
+\`target_release\` da Task em execução deve ser o release corrente de \`.agents/config/release-cycle.json\`. PRD/SPEC futuros podem ficar em draft; Tasks futuras não entram em execução antes do avanço auditável do ciclo. Um pedido de deploy não faz merge cego de toda branch: integra apenas trabalho atribuído e verificado, executa o gate de release e explica bloqueios concretos.
 Falta de prova termina \`blocked\`; erro técnico impeditivo comprovado termina
 \`failed\`. Não diminua ACs nem use duração como critério de desistência.
 `,s=`# SPECs
@@ -100,6 +106,12 @@ com causa, não permanecem \`planned\` indefinidamente. Só Tasks de DAG
 planejada com escopos independentes podem paralelizar.
 A política gerenciada não intercepta chamadas nativas externas do Codex.
 Não ative outra forma de execução nem migre estados legados implicitamente.
+
+## Isolamento de frentes
+
+SPEC serial usa o checkout compartilhado e não cria branch para cada Task. Uma frente paralela ganha worktree e branch próprios apenas quando o plano declara \`independent_branches\`, concorrência efetiva maior que um e dependências e \`write_scopes\` disjuntos entre Tasks prontas. O comando \`zaip task workspace TASK-ID --run RUN-ID\` valida essas condições; flags isoladas não autorizam paralelismo.
+
+Uma SPEC para release futuro pode ser escrita em draft. A promoção para ready/execução e as Tasks derivadas respeitam o \`current_release\`; finalize o release atual e avance o manifesto antes de executá-la.
 `,c=`# PRDs
 
 Use PRD para uma iniciativa de produto com multiplas capacidades ou SPECs.
@@ -155,6 +167,10 @@ inviabilizados e confirme todos os resultados terminais; nunca entregue por
 sucesso isolado de um ramo. Paralelismo exige DAG e escopos independentes.
 A política gerenciada não intercepta chamadas nativas externas do Codex.
 Não ative outra forma de execução nem migre estados legados implicitamente.
+
+## PRD atual e futuro
+
+O PRD pode registrar \`target_release\` futuro em draft para planejamento antecipado. Ready/execução e criação de Tasks executáveis exigem o release corrente. Na execução serial, as Tasks compartilham o checkout com escritor único; worktrees persistentes só surgem para frentes independentes com DAG, escopos disjuntos e concorrência ativa. O mesmo chat pode coordenar várias Tasks, mas cada posse de escrita é atribuída à Task/Run central.
 `,l=`# Execucao
 
 1. Confirme Task, Change, Execution, aceite e Run do orquestrador responsável, preservando o pai quando delegado pelo macro.
@@ -207,6 +223,12 @@ o relay aceita filho já terminal enquanto o responsável estiver aberto.
 Sem decisão, preserve a pendência; não infira aprovação do status nativo.
 Após decisão persistida, reconcilie \`closure_pending\` sem executar outro Gui
 ou recomeçar os workers. Veja [recuperação](16-lifecycle-e-reconciliacao.md).
+
+## Posse e fechamento do checkout
+
+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.
 `,u=`# Revisao e validacao
 
 1. Revise Requirements e criterios de aceite.
@@ -950,6 +972,12 @@ no início. Esse contrato imutável satisfaz a alternativa ao executor capturado
 sem criar Sub-Run fictício nem converter retrospectivamente uma raiz antiga.
 Revisão aplicável, Evidence e decisão real de Gui continuam obrigatórias;
 uma autorização humana apenas no texto não substitui o contrato capturado.
+
+## Escritor entre chats e recuperação de checkout
+
+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.
 `,b=`# Como o custo é calculado
 
 Cada estimativa de custo começa em tokens de uma chamada LLM capturados por fonte aceita. O dashboard não estima uso ausente: tokens ou custo sem os componentes necessários permanecem indisponíveis. Uma duração estimada é uma derivação identificada por proveniência e não preenche telemetria de uso.
@@ -1262,6 +1290,10 @@ Isso evita fabricar trabalho apenas para fechar o estado. Não permite sucesso:
 explicitamente autorizada, mesmo que existam Evidences aprovadas.
 
 O ratchet de cobertura nunca reduz o piso: 80% para lines, functions e statements e 75% para branches. Uma medição atual abaixo disso pode ser registrada como baseline observada para diagnóstico, mas o gate continua vermelho. Release crítica também exige unit, E2E, arquitetura, CQRS, módulos, profile, segurança, testes negativos, paridade da distribuição e cleanroom do candidato exato.
+
+## 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
 
 Este guia descreve o contrato e não declara cobertura, totais ou preços de um período como estado atual.
@@ -1408,6 +1440,12 @@ O controle de quotas depende do despacho gerenciado, não do desenho do fluxo.
 
 ## Lifecycle e operação
 
+### Regra de checkout e deploy
+
+Roteie a Task avulsa e o PRD/SPEC serial para o escritor único do checkout compartilhado, confirmado por \`zaip task workspace TASK-ID --run RUN-ID\`. Só abra frente com branch e worktree quando o DAG prova independência e escopos disjuntos com concorrência ativa. A coordenação por chat não confere posse de arquivo.
+
+Quando o usuário pede deploy de release, a sequência é: conciliar cada frente atribuída, fechar checkout/branch com backup verificável, congelar e auditar o release corrente, qualificar o candidato com checks locais no SHA exato, enviar apenas \`main\`, exigir CI remoto verde no mesmo SHA, publicar pelo fluxo configurado e observar a publicação. Se não for possível satisfazer duas frentes ou houver trabalho sem proveniência, faça replan dentro do orçamento e pare com bloqueio concreto se a condição permanecer. Não una branches apenas pelo nome nem prometa deploy do provedor com base no push Git.
+
 O caminho de sucesso é Definição → Planejamento → Pronto para Executar → Execução → Verificação → Concluído. Bloqueado, Falhado e Cancelado são saídas alternativas. Conversation usa uma Execution \`interaction\`; Task avulsa pedida para executar inicia com subagentes Codex no alvo v4; Task preparada espera \`execute\`; SPEC coordena Tasks; PRD coordena SPECs selecionadas. Criação explícita de macro permanece \`draft\`, salvo \`ready\`/\`execute\` também pedidos; criar e executar no mesmo turno usa Runs separadas.
 
 ![Lifecycles de Task, SPEC e PRD](assets/diagrams/lifecycles-task-spec-prd.png)
@@ -1512,9 +1550,41 @@ não crie outra Task ou apague \`.local\` para renovar a quota.
 
 | Modelo | Papel dentro da política ZAIP |
 | --- | --- |
-| \`gpt-6-luna\` | Execução clara e delimitada, conforme catálogo e capacidade |
-| \`gpt-6-sol\` | Implementação, testes, integração, planejamento difícil, revisão especializada e primeiro replanejamento |
-| \`gpt-6-astra\` | Replanejamentos e exceção de execução permitidos pelo preset |
+| \`gpt-6-luna\` | Implementação/testes simples, locais e delimitados: low; alto volume delimitado conforme sinais |
+| \`gpt-6-sol\` | Execução padrão: medium; complexidade/ambiguidade alta: high; reviewer/Gui: medium; auditor: high |
+| \`gpt-6-astra\` | Diagnóstico crítico difícil evidenciado e replanejamento/execução autorizados a partir do terceiro plano: high |
+
+Os antigos \`gpt-5.6-terra\` e \`gpt-5.6-sol\` migraram para \`gpt-6-sol\`;
+\`gpt-5.6-luna\` migrou para \`gpt-6-luna\`. A preferência Sol do catálogo é um
+baseline. Ela não substitui a política de um perfil persistido nem altera os
+nomes dos modelos em registros históricos.
+
+Na Task avulsa, declare os sinais reais com \`--model-signals JSON\` durante
+\`conversation start --intent new-work\` ou \`task prepare\`: fase, complexidade,
+transversalidade, ambiguidade, rework/custo, boundedness, volume, gatilhos e
+sinais de risco. O preparo conserva \`model_profile\`; risco conflitante é
+rejeitado. Sem perfil, Tasks históricas seguem Sol conservadoramente, sem
+inferir simplicidade pelo risco ou pela quantidade de arquivos.
+
+Com \`model_orchestration.mode: auto\`, as rotas gerenciada e nativa usam o mesmo
+resolvedor para execução normal. \`execution native-next\` recebe
+\`--host-capabilities PATH\` com JSON validado de capacidades observadas do host.
+Sem capacidade para o modelo/effort escolhido, a chamada fica bloqueada e não
+troca Luna por Sol silenciosamente. O seletor do principal permanece manual.
+
+Uma retomada nativa com plano congelado válido conserva \`executor_model\`,
+ordinal e preset; \`investigate\` declara ferramentas somente de leitura e
+nenhum write scope. Sem plano estruturado/contexto observado, a rota retorna
+indisponibilidade de recuperação. A declaração do envelope exige aplicação
+preventiva pelo host; não comprova uma chamada de LLM nem sua telemetria.
+
+\`task repair-verification\` já reserva a reparação observada. \`native-next\` não
+abre outro executor sobre essa reserva: continue pelo percurso autorizado de
+reparação, qualifique o novo candidato e use \`task settle-repair\`. A reserva
+permanece pendente até a Validation correspondente; ela não é falha nem plano
+novo. Um resumo de replanejamento sem JSON estruturado também não determina
+executor Astra. Referências externas de recuperação precisam resolver Evidence
+canônica da mesma Task, Change e Execution; IDs inexistentes não autorizam retry.
 
 Esses são papéis configurados pelo ZAIP, não alegações de benchmark dos
 modelos. Disponibilidade e esforços aceitos precisam ser confirmados no host.
@@ -1594,7 +1664,7 @@ Configurações antigas mantêm o contrato legado, não os presets acima:
 - Sinais persistidos de complexidade, ambiguidade, transversalidade, rework,
   risco e papel definem o perfil e motivos. Quantidade de arquivos ou
   departamento não substitui esses sinais.
-- Luna/Terra/Sol usam esforços permitidos pelo projeto; \`xhigh\` é
+- Luna/Sol usam esforços permitidos pelo projeto; \`xhigh\` é
   excepcional para planejamento/auditoria difícil, não um padrão para tudo.
 - Astra legado é diagnóstico read-only condicionado e limitado a três
   invocações por Task estável. Esse teto **não se aplica** ao Persistente.
@@ -1769,10 +1839,13 @@ O ratchet usa o maior valor entre o floor atual e o baseline versionado. Uma med
 
 ## Gates agregados e diagnósticos
 
-A preparação local do mantenedor executa a bateria completa \`full-v2\`, incluindo
-\`pnpm qualify:full\`, cobertura com ratchet, contratos, clean-room, Dashboard E2E
-e identidade do consumidor. Somente o SHA limpo aprovado recebe recibo assinado,
-manifesto, SBOM e TGZ. Falha ou dados incompletos não produzem aprovação.
+A preparação local de Release usa por padrão \`essential-v3\`: integridade, build/tipos,
+pacote exato e smoke limpo de consumidor. \`full-v2\`, incluindo \`pnpm qualify:full\`,
+cobertura com ratchet, contratos e Dashboard E2E, é seleção explícita para qualificação
+estendida, não o padrão de cada edição ou push. Commits usam checks proporcionais ao
+impacto; instalador/segurança diretamente alterados mantêm seus testes discriminantes.
+Somente o SHA limpo aprovado recebe recibo assinado, manifesto, SBOM e TGZ.
+Falha ou dados incompletos não produzem aprovação.
 
 No GitHub, checks de fonte (\`quality.yml\`), commits (\`commit-policy.yml\`) e matriz
 completa (\`qualify-cli.yml\`) ficam manuais. As mesmas validações principais são
@@ -1989,6 +2062,14 @@ O benchmark comparativo histórico T08 permanece sem aprovação. Otimizações
 com testes de correção e uma release publicada não comprovam economia ou SLA.
 Não repita automaticamente a matriz histórica falha: preserve o diagnóstico e
 defina uma medição independente com artefatos identificados e falhas observadas.
+
+## Ciclo corrente, limpeza e CI da main antes da Release
+
+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 4.5\`. Se uma Task de coordenação de release precisa ficar em execução durante o corte, ela deve ser crítica, alvo corrente, ter escopos exclusivos de release e Run raiz ativa; declare seus IDs com \`--release-task TASK-ID --release-run RUN-ID\`. Esses IDs ficam no manifesto frozen. Finalize Task/Run e inclua seus records no commit candidato final antes de \`audit\`; \`audit\` e \`advance\` verificam estado concluído e conteúdo exato desses records no SHA. Uma Task genérica com escopos amplos não recebe exceção.
+
+Com candidato limpo em SHA exato, execute \`node scripts/release-cycle-gate.mjs audit --repository ROOT --version 4.5 --sha SHA\`. O deploy crítico/de release executa os checks locais fixos nesse SHA, envia apenas \`main\` ao GitHub e espera o workflow \`pre-main-candidate\` verde para o push exato antes de publicar a Release. Falha dos checks locais bloqueia o push; falha de CI ou credenciais indisponíveis bloqueia a Release e exige reparo em \`main\`. Após tag, GitHub Release, main e CI exatos serem observados e todas as Tasks correntes ficarem terminais, \`node scripts/release-cycle-gate.mjs advance --repository ROOT --from 4.5 --to 4.6 --sha SHA --ci-run-id ID\` registra a transição. Isso não afirma deploy de provedor nem publicação npm; cada superfície tem prova própria. Esta seção descreve o contrato, não declara 4.5 congelada ou publicada.
 `,A=`# Telemetria Git-native do Codex
 
 Este documento descreve o comportamento implementado da telemetria do Codex no ZAIP-AIOS. O
@@ -2185,7 +2266,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 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',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 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)
 
 [English](README-ENG.md) | Português
 
@@ -3102,6 +3183,14 @@ node .agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs
 \`\`\`
 
 O [guia de Obsidian para rastreabilidade ZAIP](guide/CRIAR-PASTA-OBSIDIAN.md) documenta a instalação do aplicativo, a abertura da pasta como vault, a geração de uma única Task e a atualização da projeção após um \`git pull\`.
+
+## Branches, worktrees e release corrente
+
+Uma branch guarda uma linha de commits; um worktree é outra pasta de checkout. Editar uma Task avulsa ou um PRD/SPEC serial não precisa criar nenhum dos dois: \`zaip task workspace TASK-ID --run RUN-ID\` registra um escritor por vez no checkout compartilhado. Só frentes paralelas comprovadamente independentes recebem branch e worktree. Validação isolada curta usa checkout detached em \`.local/worktrees/validation\`.
+
+Ao encerrar frente isolada, o ZAIP inventaria arquivos, verifica bundle e snapshot locais em \`.local/backup-branchs\` e \`.local/backup-worktrees\`, testa restauração e só então fecha branch/worktree. Trabalho sem proveniência no checkout compartilhado ou backup inválido bloqueia a limpeza, com motivo para reconciliação. Os backups ficam ignorados pelo Git para consulta; a remoção deles é manual.
+
+\`.agents/config/release-cycle.json\` define o release executável. PRD/SPEC de um release futuro podem ficar em draft. Para publicar o release atual, é preciso conciliar e fechar frentes atuais, congelar e auditar o SHA candidato, executar os checks locais fixos, publicar apenas \`main\` e exigir CI remoto verde nesse mesmo SHA antes da Release. Observe separadamente tag, GitHub Release, npm e destino de deploy aplicável. \`node scripts/release-cycle-gate.mjs advance --repository . --from 4.5 --to 4.6 --sha SHA --ci-run-id ID\` só abre o ciclo seguinte após essas provas e Tasks correntes terminais. A presença de branches antigas ou da Task atual aberta bloqueia a auditoria; este texto não declara um release feito.
 `,P=n(),F=Object.assign({"../../../../zaip-aios/guides/01-primeiros-passos.md":i,"../../../../zaip-aios/guides/02-requirements.md":a,"../../../../zaip-aios/guides/03-tasks.md":o,"../../../../zaip-aios/guides/04-specs.md":s,"../../../../zaip-aios/guides/05-prds.md":c,"../../../../zaip-aios/guides/06-execucao.md":l,"../../../../zaip-aios/guides/07-revisao-e-validacao.md":u,"../../../../zaip-aios/guides/08-contexto-e-tokens.md":d,"../../../../zaip-aios/guides/09-agentes-e-squads.md":f,"../../../../zaip-aios/guides/10-seguranca.md":p,"../../../../zaip-aios/guides/11-observabilidade-e-custos.md":m,"../../../../zaip-aios/guides/12-instalacao-e-upgrade.md":h,"../../../../zaip-aios/guides/13-boas-praticas.md":g,"../../../../zaip-aios/guides/14-troubleshooting.md":_,"../../../../zaip-aios/guides/15-tools-e-codex.md":v,"../../../../zaip-aios/guides/16-lifecycle-e-reconciliacao.md":y,"../../../../zaip-aios/guides/17-como-o-custo-e-calculado.md":b,"../../../../zaip-aios/guides/18-catalogo-de-agentes.md":x,"../../../../zaip-aios/guides/19-assurance-e-autonomia.md":S,"../../../../zaip-aios/guides/20-instalacao-detalhada.md":C,"../../../../zaip-aios/guides/21-telemetria-monitor-custos.md":w,"../../../../zaip-aios/guides/22-fluxos-e-roteamento.md":T,"../../../../zaip-aios/guides/23-orquestracao-de-modelos.md":E,"../../../../zaip-aios/guides/24-calculo-de-custos-openai.md":D,"../../../../zaip-aios/guides/25-fontes-de-precos-openai.md":O,"../../../../zaip-aios/guides/26-qualidade-e-release.md":k,"../../../../zaip-aios/guides/27-telemetria-git-native.md":A,"../../../../zaip-aios/guides/28-lifecycle-completo.md":j});function I({locale:e,onClose:t}){let n=(0,M.useMemo)(()=>r(e,N,F),[e]),i=n.filter(e=>e.id!==`readme`),[a,o]=(0,M.useState)(`readme`),[s,c]=(0,M.useState)(`rendered`),l=n.find(e=>e.id===a)??n[0];return(0,P.jsx)(`div`,{className:`dashboard-help-backdrop`,children:(0,P.jsxs)(`section`,{"aria-label":e===`pt-BR`?`Ajuda do ZAIP-AIOS`:`ZAIP-AIOS help`,"aria-modal":`true`,className:`dashboard-help`,role:`dialog`,children:[(0,P.jsxs)(`header`,{children:[(0,P.jsxs)(`div`,{children:[(0,P.jsx)(`span`,{children:e===`pt-BR`?`Documentação local`:`Local documentation`}),(0,P.jsx)(`h2`,{children:e===`pt-BR`?`Ajuda e guides do framework`:`Framework help and guides`})]}),(0,P.jsx)(`button`,{"aria-label":e===`pt-BR`?`Fechar ajuda`:`Close help`,onClick:t,type:`button`,children:`×`})]}),(0,P.jsxs)(`div`,{className:`dashboard-help-layout`,children:[(0,P.jsxs)(`nav`,{"aria-label":e===`pt-BR`?`Documentos de ajuda`:`Help documents`,children:[(0,P.jsx)(`strong`,{children:e===`pt-BR`?`Visão geral`:`Overview`}),(0,P.jsx)(`button`,{className:a===`readme`?`is-active`:void 0,onClick:()=>o(`readme`),type:`button`,children:`README · ZAIP-AIOS`}),(0,P.jsx)(`strong`,{children:e===`pt-BR`?`Aprofundar no framework`:`Framework guides`}),i.map(e=>(0,P.jsx)(`button`,{className:a===e.id?`is-active`:void 0,onClick:()=>o(e.id),type:`button`,children:e.title},e.id))]}),(0,P.jsxs)(`article`,{children:[(0,P.jsxs)(`div`,{className:`dashboard-help-document-header`,children:[(0,P.jsx)(`h3`,{children:l?.title}),(0,P.jsxs)(`fieldset`,{"aria-label":e===`pt-BR`?`Visualização do documento`:`Document view`,children:[(0,P.jsx)(`button`,{"aria-pressed":s===`rendered`,className:s===`rendered`?`is-active`:void 0,onClick:()=>c(`rendered`),type:`button`,children:e===`pt-BR`?`Renderizado`:`Rendered`}),(0,P.jsx)(`button`,{"aria-pressed":s===`source`,className:s===`source`?`is-active`:void 0,onClick:()=>c(`source`),type:`button`,children:`Markdown`})]})]}),(0,P.jsx)(`div`,{className:`dashboard-help-sections`,children:W(l?.content??``,e).map(e=>(0,P.jsxs)(`section`,{children:[(0,P.jsx)(`h4`,{children:e.title}),s===`rendered`?(0,P.jsx)(L,{content:e.content}):(0,P.jsx)(`pre`,{children:e.content})]},e.title))})]})]})]})})}function L({content:e}){return U(R(e),H).map(({key:e,value:t})=>t.kind===`table`?(0,P.jsx)(`div`,{className:`dashboard-help-table-scroll`,children:(0,P.jsxs)(`table`,{children:[(0,P.jsx)(`thead`,{children:(0,P.jsx)(`tr`,{children:U(t.headers,e=>e).map(({key:e,value:t})=>(0,P.jsx)(`th`,{children:V(t)},e))})}),(0,P.jsx)(`tbody`,{children:U(t.rows,e=>e.join(``)).map(({key:e,value:t})=>(0,P.jsx)(`tr`,{children:U(t,e=>e).map(({key:e,value:t})=>(0,P.jsx)(`td`,{children:V(t)},e))},e))})]})},e):(0,P.jsx)(`pre`,{children:t.content},e))}function R(e){let t=e.split(`
 `),n=[],r=[],i=()=>{let e=r.join(`
 `).trim();e&&n.push({kind:`text`,content:e}),r=[]};for(let e=0;e<t.length;e+=1){let a=t[e],o=t[e+1];if(a?.includes(`|`)&&o&&z(o)){i();let r=B(a),o=[];for(e+=2;e<t.length&&t[e]?.includes(`|`);)o.push(B(t[e]??``)),e+=1;--e,n.push({kind:`table`,headers:r,rows:o});continue}r.push(a??``)}return i(),n}function z(e){return B(e).every(e=>/^:?-{3,}:?$/.test(e.replace(/\s/g,``)))}function B(e){return e.trim().replace(/^\|/,``).replace(/\|$/,``).split(`|`).map(e=>e.trim())}function V(e){return U(e.split(/(\*\*[^*]+\*\*)/g),e=>e).map(({key:e,value:t})=>t.startsWith(`**`)&&t.endsWith(`**`)?(0,P.jsx)(`strong`,{children:t.slice(2,-2)},e):(0,P.jsx)(M.Fragment,{children:t},e))}function H(e){return e.kind===`text`?`text:${e.content}`:`table:${e.headers.join(``)}:${e.rows.map(e=>e.join(``)).join(``)}`}function U(e,t){let n=new Map;return e.map(e=>{let r=t(e),i=(n.get(r)??0)+1;return n.set(r,i),{key:`${r}#${i}`,value:e}})}function W(e,t){return e.split(/\n(?=##?\s)/).filter(Boolean).map((e,n)=>{let r=e.trim().split(`

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

@@ -1 +1 @@
-import{n as e}from"./rolldown-runtime-Bh1tDfsg.js";import{E as t,w as n}from"./cost-monitor-D7PrDZy9.js";import{n as r}from"./dashboard-localization-CF7B1Hjn.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-fTQhSL85.js";import{n as r}from"./dashboard-localization-CF7B1Hjn.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};