Runbook de operações

O handoff para o operador: como o sistema é entregue, executado e observado, descrito em nível de arquitetura. Os comandos exatos do operador vivem na referência privada de comandos de operador; esta página é a referência pública da forma operacional, e cada seção liga à página que a documenta em profundidade.

Responsabilidades do operador

O sistema é construído para que nenhum passo de release dependa de o operador lembrar de fazer a coisa certa à mão.

A entrega é automática, não manual. Um release é uma tag vX.Y.Z; uma matriz de CI verde nessa tag exata é o gate, e o deploy roda no lado do servidor apenas depois que a matriz passa. Nenhum operador publica um release de produção à mão. Veja Deploy.
A observação é contínua. Cada nó, chamada de modelo, recuperação e guardrail emite um trace, e orçamentos de custo e latência são impostos por turno. Veja Observabilidade.
A resposta é uma operação de tráfego. O rollback desvia o tráfego para a revisão sadia anterior instantaneamente, sem rebuild; uma revisão que falha nunca assume o tráfego.
As mudanças aplicadas pelo operador são aditivas e explícitas. Os poucos ajustes que um operador aplica - habilitar a revisão humana durável, ou trocar scale-to-zero por uma instância quente - são aditivos, nunca um reset completo do ambiente.

Pronto para produção: definição de pronto

“Pronto para produção” aqui é uma lista com evidência, não uma sensação. Um release está pronto quando:

A matriz completa de CI está verde no commit taggeado exato - este é o gate de deploy; uma matriz vermelha significa que nada é publicado.
O deploy é sem chaves (um token federado de curta duração, sem chave armazenada) e preserva segredos (o rebuild a partir da fonte mantém o ambiente e os vínculos de segredos existentes do serviço). Veja Deploy.
A documentação pública passa em sua verificação de vazamento fail-closed, de modo que nenhum caminho interno, identificador privado ou constante ajustada chega ao site público.
O gate de avaliação passa: pontuadores deterministas em cada mudança, os limiares de corpus apoiados pelo juiz na execução noturna, e o gate de calibração do juiz armado em fail-closed sobre as duas dimensões de segurança (escalonamento e autolesão).
O piso de segurança se sustenta: as categorias deterministas de emergência aguda fazem curto-circuito antes de qualquer chamada de modelo e nunca são condicionadas atrás da revisão humana.
Os gates de acessibilidade e de regressão visual do frontend passam.
Os trilhos de segurança são impostos na revisão em execução: origin-lock na borda, a verificação de bot, o consentimento por chave, e os limitadores de taxa e de concorrência. Veja Segurança.

Executar e observar

Cadência de deploy. Tag, então o gate de CI reexecuta a matriz completa nessa tag, então o deploy roda apenas no verde, então o tráfego é desviado assim que a nova revisão está sadia.
O que observar. Spans do OpenTelemetry ao longo de cada nó e chamada de modelo; o sinal de saúde do juiz na avaliação noturna; os sinais de drift do Plano de detecção de drift; e a trilha do Plano de audit logging.
Keep-warm. Um agendador externo faz ping em uma rota keep-warm de tempo constante para suavizar os cold starts sem manter uma instância sempre ligada.

Custo e SLOs

O custo em estado estável é um alvo de projeto. O serviço roda scale-to-zero, então o tráfego em escala de demo fica dentro da cota sempre-gratuita do host e o gasto em estado estável fica perto de $0 / mês. Esta é uma postura de portfólio deliberada; um SLA de produção e escalonamento multi-tenant estão fora de escopo para a demo pública.
O custo é medido como se fosse pago. O custo de tokens e computação por turno é precificado a taxas reais de pagamento por uso e medido no lado do servidor; um disjuntor rígido de gasto diário e um teto mensal interrompem o gasto descontrolado e reiniciam em uma cadência fixa.
Os orçamentos por turno são impostos. Orçamentos de tokens e latência limitam cada turno; um turno que os excederia é interrompido em vez de servido sem limite.
Existe um caminho de UX de produção. Um operador que precisa remover o cold start pode rodar uma instância quente e sempre ligada por um pequeno custo mensal fixo; é um ajuste aditivo, aplicado pelo operador, nunca auto-aplicado à demo. O blueprint com custos está no enterprise agent stack.

Human-in-the-loop e durabilidade

A revisão humana de um rascunho de alto risco mas não agudo é uma capacidade opt-in, desligada por padrão. Ela compila no grafo do agente apenas quando habilitada, e habilitá-la em produção exige um checkpointer durável (um armazenamento de conversa apoiado por Postgres) e uma instância quente, para que um turno pausado sobreviva a uma reciclagem de scale-to-zero. Emergências agudas nunca dependem dela: as categorias agudas deterministas são tratadas antes de o modelo rodar e ignoram a revisão humana por completo.

Postura de incidentes e rollback

O rollback é instantâneo e sem rebuild: desvia o tráfego para a revisão sadia anterior.
Avança uma correção revertendo o commit ofensor e cortando uma nova tag, que reexecuta o gate e, no verde, refaz o deploy.
Os disjuntores de gasto falham seguro: disparam sobre o gasto medido e reiniciam em uma cadência fixa, então um incidente de custo fica limitado automaticamente.
O endpoint público de topologia não carrega segredos: retorna apenas os nomes de nó do grafo compilado, as arestas e os booleanos de feature, e um teste de CI permanente tranca esse contrato.