# Pedido restrito de força da atualização

Destino: infraestrutura. A atualização da instalação continua necessária com zero extensões ativas. A tela usa as rotas nativas; o app não recebe acesso ao Docker. Fontes originais: @webtecnica no PR #3413 e @vitorlacerdadigital no PR #3417, preservadas por merges normais.

O clique envia somente `{ force: true }`. A rota revalida dono, MFA, suporte, a última falha e a identidade oficial confirmada. O run nativo guarda `force_requested`; o próximo heartbeat entrega o booleano e o alvo derivado. O agente monta um array de argumentos de `update.sh`, aceitando apenas o formato numérico de tag e a flag fixa `--force`. A mesma tag também recebe a força pedida. O caminho normal continua false.

A capacidade é anunciada pelo próprio `agent.sh` em execução no campo de topo `supports_forced_update`. O endpoint não aceita que o helper do disco conceda essa capacidade: anúncio ausente no topo sobrescreve o valor dentro da observação para false. Heartbeat legado limpa a confirmação. Se uma força já estiver enfileirada e a execução que a busca não confirmar essa capacidade, a rota encerra o run como falha com condição de status e audita somente o encerramento efetivo; o host também recusa força sem observação válida. A capacidade só é mostrada com identidade oficial recente e não autoriza substituir uma revisão personalizada.

A identidade e o desfecho são informações diferentes. A falha não desaparece por uma versão declarada num único processo. A tela mantém o cartão da versão instalada e a explicação até existir observação posterior coerente. Falta de suporte ou confirmação não oferece o botão de força como se o host fosse executá-lo. O log e a auditoria registram o pedido; só o recibo do agente e a observação posterior demonstram execução e retorno ao ar.

A imagem de voz entrega um probe TCP no listener AudioSocket já existente, em loopback. Conectar sem enviar UUID não cria chamada nem consulta o banco. Porta inválida, recusa e prazo excedido falham; ARI, SIP, áudio e chamada não são medidos por essa sonda. A sonda nativa de imagem precisa observar o healthcheck saudável, preservando seus controles de boot e o orçamento anterior. Voz existente, ainda que parada, não desaparece da confirmação; instalações sem voz não ativam esse perfil por causa do monitor.

Provas leves desta implementação: rotas/componentes/identidade dirigidos, harness do agente completo com updater e infraestrutura simulados, controles reais de socket no próprio harness e sabotagens causais. Isso não é uma atualização de VPS, imagem construída ou prova de UX. A bancada PG17 confirmou install/update, preservação de runs antigos, defaults, replay duas vezes e controles por papel com leitura posterior dos dados. O primeiro replay do baseline tem uma deriva histórica da view de calendário e de um comentário, reproduzida integralmente na main literal; o segundo estabiliza, e o candidato permanece exatamente main mais as duas colunas. Dois raws CLI2.122 integrais e dois formatados saíram iguais; a AST inteira da main foi preservada com somente seis propriedades adicionadas, e o arquivo de tipos foi promovido integralmente. Os JWTs HTTP reais seguem pendentes para o CI, pois essa lane não tinha Auth/PostgREST identificado; SET ROLE não é essa prova. A QA proposta reusa os oito casos de `system-update.spec.ts`, com heartbeat autenticado simulado e uma sessão JWT real do Auth de teste. O fetch dos clientes SDK desse helper tem prazo de 5 s e preserva abort externo; a fase JWT tem step de 20 s dentro do caso original de 30 s. A publicação DRAFT mede essa composição; os envelopes de planejamento não são prova visual ou duração observada.

Laço de retorno: uma recusa permanece no run e na explicação da tela; a confirmação velha ou incompleta retira a ação, uma nova batida válida recompõe a elegibilidade. Não há retry novo nem aprendizado automático. O mapa de atualização liga pedido, run, agente e desfecho; o run continua a fonte única do trabalho pendente.