# Estrategia De Deploy Independente Para Product E Admin

Este documento define a estrategia de deploy para manter `orquestrador-product`
e `orquestrador-admin` como servicos distintos, porem ligados.

## Objetivo

Permitir que:

- o atendimento continue estavel mesmo se o admin estiver fora do ar
- o admin evolua com login, painel, relatorios e geracao de tools sem impactar o hot path
- os dois servicos possam ser versionados e publicados com cadencias diferentes

## Servico de produto

Nome operacional sugerido:

- `orquestrador-product`

Responsabilidades:

- Telegram
- orquestracao
- execucao de tools publicadas
- regras operacionais do atendimento

Unit `systemd` sugerida:

- `deploy/systemd/orquestrador-product.service.example`

## Servico administrativo

Nome operacional sugerido:

- `orquestrador-admin`

Responsabilidades:

- autenticacao interna
- painel administrativo
- relatorios
- configuracao do sistema
- geracao, validacao, aprovacao e publicacao de tools

Unit `systemd` sugerida:

- `deploy/systemd/orquestrador-admin.service.example`

## Principios

1. Deploy do `admin` nao deve exigir restart do `product`.
2. Deploy do `product` nao deve depender do `admin` estar online.
3. Mudancas em `shared/contracts` devem ser compativeis para frente e para tras durante a janela de rollout.
4. O `product` consome somente estado publicado e aprovado.
5. O `admin` nao entra no hot path do atendimento.

## Configuracao de ambiente

Sugestao de arquivos distintos:

- `.env.product`
- `.env.admin`

### `product`

Mantem:

- Vertex do atendimento
- Redis do estado conversacional
- Telegram
- bancos do runtime operacional

### `admin`

Mantem:

- credenciais do painel interno
- banco administrativo
- modelo de geracao de codigo
- configuracoes de relatorios e publicacao

## Estrategia de rollout

### Mudancas so no admin

1. publicar codigo do `admin`
2. atualizar dependencias do `admin`
3. reiniciar apenas `orquestrador-admin`

### Mudancas so no product

1. publicar codigo do `product`
2. atualizar dependencias do `product`
3. reiniciar apenas `orquestrador-product`

### Mudancas em contratos compartilhados

1. publicar contrato novo de forma aditiva
2. subir primeiro o servico consumidor mais tolerante
3. subir o outro servico depois
4. so remover campos antigos numa fase posterior

## Banco e publicacao de estado

Nesta fase, a estrategia recomendada e:

- `admin` grava seus proprios metadados e artefatos
- `product` consome somente dados publicados e estaveis
- nenhuma dependencia sincrona do `product` para consultar `admin` em tempo de atendimento

## Observabilidade

Cada servico deve ter:

- logs proprios
- unit `systemd` propria
- variaveis de ambiente proprias
- healthcheck proprio

## Situacao atual

Hoje o runtime real em producao ainda e o de `product`.

Esta estrategia ja prepara o caminho para:

- manter o deploy atual do produto
- introduzir o `admin` como segundo servico
- fazer a transicao sem mover `app/` agora