Requisição 201 — Atualização do sistema por API, com opções, para o host-manager e para várias instâncias

Origem: Humano, 2026-09-30: "criar rotinas automatizadas de atualização via API, de atualização do sistema, com todo esse rollback", para o host-manager do conn2flow-site disparar nos tenants, e um CLI para atualizar todos. Lotes Vinculados: BATCH-209 (core: API em segundo plano, update:core). O lado privado (CLI em massa, host-manager) fica no conn2flow-site, em requisição de lá. Status: parte do core implementada (BATCH-209 complete, 2026-09-30; homologação humana pendente). Pendente: requisição no conn2flow-site para o CLI em massa e o host-manager. Repositório: [REDACTED]; o consumo fica no conn2flow-site (host-manager), em requisição própria de lá.

Contexto

• Já existe /_api/system/update, com as etapas da atualização pelo painel (start, deploy, db, finalize, status, cancel), que grava snapshot e dump (req-198).

• A verificação com volta automática, o rollback e as opções (--no-health, --health-url…) existem só no CLI do atualizador (BATCH-203) e no deploy de projeto por API (BATCH-204).

• O pacote vem sempre do GitHub (release do gestor), não enviado pela requisição.

Rascunho dos itens (a detalhar)

1. Disparo em uma chamada, com opções: tag (ou a última do GitHub), dry_run, only_db/no_db, backup, no_health, no_rollback, health_url/health_ip; execução em segundo plano no servidor, com id da execução para acompanhar.

2. Acompanhamento: status com as etapas, o relatório, o snapshot, a verificação e os choques.

3. Rollback da execução pela API (arquivos; banco opcional), igual ao /_api/project/rollback.

4. Verificação e volta automática também no caminho web/API da atualização do sistema.

5. CLI em massa: atualizar várias instâncias (uma por vez ou em lotes, parar no primeiro erro opcional, relatório por instância).

   • Decisão do Humano (2026-09-30): o CLI em massa e o consumo pelo host-manager ficam no conn2flow-site (repositório privado, instância master), em requisição de lá. O core (conn2flow, open source) entrega só a API de atualização do sistema, com as opções e o rollback. Regra geral: o que é privado da operação vai para o conn2flow-site; o core fica com o que serve a qualquer instalação.

6. Consumo pelo host-manager (conn2flow-site): disparo por tenant e em massa, histórico e rollback no painel.

7. Proteção do atualizador: um atualizador quebrado numa release trava as atualizações seguintes (visto no BATCH-204); prever teste do atualizador novo antes de trocar o instalado.