# DEVON AUTONOMOUS CLIENT INFRASTRUCTURE, BACKUP, RECOVERY AND FLEET OPERATIONS v1

## Objetivo

Definir a arquitetura operacional para contratação automática, provisionamento, instalação, segurança, backup, recuperação, monitoramento e failover dos servidores usados pelo Devon para clientes padrão, clientes de alta demanda, servidor principal, servidores de backup, servidores mirror e instâncias dedicadas Devon.

## Escopo

Este canon governa a infraestrutura operacional do Devon como plataforma real, escalável e automatizada.

Inclui:

- contratação automática de servidores
- plano padrão de servidor
- upgrade por monitoramento
- provisionamento por API
- bootstrap agent / installer
- hardening de segurança
- criptografia de dados
- criação de banco
- instalação de runtime
- instância Devon dedicada
- backup multi-provider
- backup físico offline
- restore test
- recovery runbook
- servidor mirror
- failover
- monitoramento central
- monitoramento por servidor de cliente
- alerta operacional
- bloqueio automático por guardrails

Fora de escopo:

- DEVON-ABOS
- Waresites como produto final
- CRM/ERP comercial final
- precificação detalhada
- contrato jurídico final
- escolha definitiva de fornecedor
- implementação técnica imediata sem evidência real do servidor

## Regra central

Escala exige automação.
Segurança exige guardrails.
Confiabilidade exige backup, restore test, mirror e monitoramento.
Intervenção humana deve ser exceção, não rotina operacional.

## Regra decisória

LLM nunca decide absolutamente nada.
LLM apenas interpreta, redige, resume ou explica.
FSM decide tudo.

## Regra comercial

Pagamento aprovado e plano contratado devem gerar autorização operacional suficiente para o provisioning padrão.

O Devon não deve exigir aprovação humana manual para cada novo cliente padrão.

A intervenção humana só deve ocorrer em exceções, disputas, risco fora do contrato, falha crítica, abuso, compliance especial ou operação não prevista pelas políticas.

## Regra operacional

O Devon automatiza o caminho padrão.
O Devon bloqueia o caminho fora do padrão.
O Devon monitora tudo em tempo real.

---

# Modelo arquitetural

## 1. Devon Control Plane

Servidor principal da operação Devon.

Responsável por:

- governança central
- painel matriz
- provisionamento
- registry de clientes
- registry de servidores
- planos contratados
- billing bridge
- policies
- FSM
- source registry
- monitoring central
- fleet status
- incident registry
- failover control
- backup registry

## 2. Standard Client Runtime Server

Servidor padrão contratado automaticamente para cada cliente comum.

Responsável por:

- projetos do cliente
- memória do cliente
- banco do cliente
- logs do cliente
- evidências do cliente
- backups locais temporários
- runtime operacional
- monitoramento local
- sandbox e produção do cliente quando aplicável

## 3. High Demand Client Runtime Server

Servidor mais potente usado quando o cliente contrata plano enterprise ou quando o painel detecta necessidade real de upgrade.

## 4. Dedicated Devon Instance

Instância Devon completa e exclusiva para cliente de alta demanda, operação crítica, compliance forte, LLM dedicado, grande volume ou necessidade de isolamento extremo.

## 5. Backup Infrastructure

Infraestrutura externa de backup com pelo menos dois provedores diferentes.

Exemplo:

- Backup Node A em Contabo
- Backup Node B em Hetzner
- cópia fria física offline opcional

## 6. Mirror / Standby Control Plane

Servidor espelho do Devon Control Plane, pronto para assumir operação crítica se o principal cair, for corrompido ou precisar ser isolado.

## 7. Fleet Monitoring

Painel central que monitora todos os servidores, runtimes, backups, mirrors, healthchecks, incidentes e alertas.

---

# Novas Phases planejadas

## Phase 11 — Client Provisioning & Server Plans Canonical

FUNÇÃO:
Governar contratação, plano padrão, pagamento aprovado, limites comerciais, API de provedor, criação de servidor e upgrade por evidência real de monitoramento.

Categorias planejadas:

1. Standard Client Server Plan Canonical
2. Client Plan Contract Canonical
3. Billing Authorization Canonical
4. Provider API Provisioning Canonical
5. Server Purchase Policy Canonical
6. Commercial Limit Guardrails Canonical
7. Provisioning Request Registry Canonical
8. Customer Account Runtime Registry Canonical
9. Payment-to-Provisioning Bridge Canonical
10. Server Upgrade Trigger Canonical
11. Provisioning Exception Handling Canonical

## Phase 12 — Bootstrap, Security & Runtime Installation Canonical

FUNÇÃO:
Governar preparação técnica de servidores recém-criados, instalação do bootstrap agent, hardening, criptografia, banco, containers, runtime isolado e instância Devon dedicada quando aplicável.

Categorias planejadas:

1. Bootstrap Agent / Installer Canonical
2. Server Baseline Hardening Canonical
3. Secure SSH & Access Bootstrap Canonical
4. Firewall & Network Exposure Canonical
5. Encrypted Storage Baseline Canonical
6. Database Initialization Canonical
7. Runtime Container Installation Canonical
8. Dedicated Devon Installation Plan Canonical
9. Server Registration & Handshake Canonical
10. Installation Validation Gate Canonical

## Phase 13 — Backup Server & Recovery Infrastructure Canonical

FUNÇÃO:
Governar backup, retenção, criptografia, restore, backup multi-provider, backup físico offline, checksums, manifests, restore tests e recuperação para novo servidor.

Categorias planejadas:

1. Backup Server Topology Canonical
2. Primary Backup Node Canonical
3. Secondary Backup Node Canonical
4. Encrypted Backup Policy Canonical
5. Backup Key Management Canonical
6. Backup Manifest Canonical
7. Backup Replication Canonical
8. Backup Integrity Check Canonical
9. Restore Test Canonical
10. Recovery Runbook Canonical
11. Backup Retention Policy Canonical
12. Backup Incident Recovery Canonical
13. Cross-Provider Backup Governance Canonical
14. Offline Physical Backup Canonical

## Phase 14 — Fleet Monitoring, Mirror & Failover Canonical

FUNÇÃO:
Governar monitoramento em tempo real de todos os servidores, painel local de cada cliente, painel central matriz, heartbeat, mirror, failover, resposta a ataque, incidentes e continuidade operacional.

Categorias planejadas:

1. Central Fleet Monitoring Canonical
2. Client Server Monitor Canonical
3. Server Heartbeat Canonical
4. Runtime Mirror Sync Canonical
5. Provisioning Status Timeline Canonical
6. Server Health Rollup Canonical
7. Client Runtime Observability Canonical
8. Fleet Incident Registry Canonical
9. Fleet Notification Rules Canonical
10. Server Compliance Snapshot Canonical
11. Control Plane Mirror Canonical
12. Failover Controller Canonical
13. Attack Isolation & Recovery Canonical
14. Standby Promotion Gate Canonical

---

# Atualizações prioritárias antes de criar as novas Phases no DH

Estas categorias já existem no DH e devem receber backfill semântico antes da criação das novas Phases.

## 1. FSM Absolute Decision Canonical

Adicionar decisões de:

- provisioning
- autorização por pagamento aprovado
- bloqueio por exceção
- failover
- backup status
- server upgrade trigger

## 2. Decision Rule Registry Canonical

Adicionar regras:

- ALLOW_PROVIDER_API_PURCHASE
- ALLOW_SERVER_PROVISIONING
- ALLOW_BOOTSTRAP_INSTALL
- ALLOW_RUNTIME_INSTALL
- BLOCK_NON_STANDARD_INFRASTRUCTURE
- BLOCK_UNENCRYPTED_BACKUP
- BLOCK_MISSING_RESTORE_TEST
- ALLOW_FAILOVER
- BLOCK_FAILOVER_WITHOUT_STANDBY_HEALTH

## 3. Tool Registry Canonical

Adicionar tools:

- provider_api_create_server
- provider_api_destroy_server
- provider_api_resize_server
- install_bootstrap_agent
- run_hardening_plan
- configure_backup
- run_restore_test
- promote_standby
- isolate_server
- sync_runtime_mirror

## 4. Server Workspace Manager Canonical

Adicionar roles de servidor:

- standard_client_runtime
- high_demand_runtime
- dedicated_devon_instance
- backup_server
- mirror_server
- monitoring_node

## 5. Environment Registry Canonical

Adicionar ambientes:

- client_runtime_environment
- backup_environment
- mirror_environment
- recovery_environment
- provisioning_environment

## 6. Shell Execution Canonical

Adicionar autoridade para:

- comandos permitidos para bootstrap
- comandos bloqueados
- hardening commands
- backup commands
- restore test commands
- failover commands

## 7. Backup & Rollback Canonical

Atualizar para:

- multi-provider backup
- encrypted backup
- restore test
- offline physical backup

## 8. Disaster Recovery Canonical

Atualizar para:

- mirror
- failover
- backup multi-provider
- attack recovery
- restore to new server

## 9. Secrets Management Canonical

Adicionar escopos:

- backup encryption keys
- provider API credentials
- bootstrap credentials
- mirror secrets
- key custody
- key rotation

## 10. RBAC / Permissions Canonical

Adicionar permissões:

- provision_server
- resize_server
- bootstrap_server
- configure_backup
- access_backup_key
- run_restore
- promote_standby
- isolate_server

## 11. Resource Governance Canonical

Adicionar:

- upgrade thresholds
- resource pressure alerts
- blocking heavy jobs
- backup window pressure
- LLM runtime capacity

## 12. Observability Core Canonical

Adicionar:

- fleet monitoring
- per-server monitoring
- provisioning timeline
- backup status
- mirror status
- failover status

## 13. Runtime Status Canonical

Adicionar estados:

- LIVE
- DEGRADED
- STALE
- LOST
- RECOVERY_MODE
- MIRROR_READY
- FAILOVER_RUNNING
- BACKUP_FAIL
- RESTORE_TEST_FAIL

## 14. SSE / Realtime Events Canonical

Adicionar eventos:

- provisioning_started
- server_created
- bootstrap_started
- bootstrap_failed
- backup_failed
- restore_test_failed
- heartbeat_lost
- failover_started
- standby_promoted
- attack_suspected
- attack_confirmed

## 15. Incident Management Canonical

Adicionar incidentes:

- provisioning failure
- bootstrap failure
- backup corruption
- restore failure
- server lost
- suspected attack
- confirmed compromise
- failover failure
- mirror stale

## 16. Notification Service Canonical

Adicionar alertas:

- upgrade needed
- backup failed
- restore test failed
- server lost
- bootstrap failed
- provider API failure
- failover activated
- attack suspected
- mirror degraded

## 17. DEVON-DEV Admin Console Canonical

Adicionar telas:

- clientes
- servidores
- planos
- provisionamentos
- backups
- restore tests
- mirrors
- failovers
- incidentes
- fleet health
- provider APIs

## 18. Container Network Policy Canonical

Adicionar regras para:

- backup nodes
- client servers
- mirror
- monitoring
- restricted services
- public/internal/restricted classification

## 19. Volume & Persistence Governance Canonical

Adicionar:

- encrypted volumes
- backup_required
- restore_path
- retention
- cleanup protection
- local physical backup

## 20. Config Registry Canonical

Adicionar:

- provider configs
- plan configs
- backup configs
- monitoring configs
- failover configs
- thresholds

---

# Status gerais

## PASS

A infraestrutura está padronizada, provisionada automaticamente, monitorada, com backup multi-provider, backup físico opcional, restore test, mirror, failover e bloqueios por guardrails.

## FAIL

Servidor é criado sem plano, sem backup, sem hardening, sem criptografia exigida, sem monitoramento, sem restore test, sem mirror ou com automação fora do contrato.

## MISSING

Faltam plano, server_id, provider_id, bootstrap_id, backup_id, key_id, manifest, restore test, heartbeat, mirror, failover rule ou fleet registry.

## BLOCKED

Qualquer operação fora do contrato, sem pagamento aprovado, sem hardening, sem backup, sem key recuperável, sem healthcheck, sem monitoramento ou com risco confirmado deve ser bloqueada pelo FSM.

---

# Regra final

Servidor padrão reduz complexidade comercial.
Upgrade por monitoramento evita gasto inútil.
Provisioning automático escala o produto.
Bootstrap Agent precisa ser autoridade própria.
Hardening precisa nascer no primeiro minuto do servidor.
Backup online precisa ser multi-provider.
Backup físico offline aumenta sobrevivência.
Criptografia só é segura se a chave for recuperável.
Backup sem restore test não é confiável.
Mirror mantém operação.
Backup recupera dados.
Mirror não substitui backup.
Backup não substitui mirror.
Failover precisa de regra objetiva.
Suspeita de ataque gera contenção.
Ataque confirmado gera isolamento.
Painel central monitora a frota.
Cada servidor precisa de monitor próprio.
O painel não inventa estado.
Tudo deve gerar evidência, status e trilha auditável.

Frase matriz:
Devon deve provisionar infraestrutura como produto, proteger dados como obrigação, recuperar operação como rotina e monitorar todos os servidores como fonte viva de verdade operacional.