# Plano proposto para o firmware v2.2.0

## Objetivo

Transformar a Controller atual em uma plataforma identificável, multi-hardware e preparada para integração remota segura, sem permitir que a nuvem ultrapasse os intertravamentos locais.

## 1. Identidade e primeiro acesso

Campos obrigatórios:

- Número de Série
- Modelo do produto
- Hardware Model ID
- Revisão de hardware

Campos de rastreabilidade:

- Número de patrimônio
- Cliente
- Endereço de instalação
- Cidade, UF e observações técnicas

O primeiro acesso deve permanecer bloqueado até a gravação do Número de Série e seleção do perfil. A edição posterior do serial exige reautenticação, confirmação textual e log de auditoria. O `device_uid` derivado na fabricação não deve mudar quando o serial for editado.

## 2. Hardware Manifest

Exemplo conceitual:

```cpp
struct HardwareManifest {
  const char* family;
  const char* modelId;
  const char* revision;
  uint32_t capabilities;
  PinDefinition pins[MAX_HW_PINS];
  BusDefinition buses[MAX_HW_BUSES];
};
```

Targets iniciais sugeridos:

- `H2O_CTRL_S3_DEVKIT_A1`
- `H2O_CTRL_S3_COMMERCIAL_A1`
- `H2O_CTRL_S3_COMMERCIAL_B1`

O firmware deve falhar em modo seguro se o manifest compilado não corresponder à identidade persistida.

## 3. Separação de configurações

- `DeviceIdentity`: específico da unidade.
- `HardwareManifest`: específico da placa/revisão.
- `ProcessProfile`: específico do modelo Ultra, Essencial ou Smart.
- `InstallationMetadata`: cliente, patrimônio e endereço.
- `CloudProvisioning`: endpoint, device ID e segredo.

Wi-Fi, credenciais e segredos nunca devem fazer parte do perfil hidráulico exportável.

## 4. Comunicação remota

Implementar uma troca HTTPS iniciada pela Controller:

```text
POST /api/v1/device/exchange
```

A requisição transporta telemetria, estado reportado e ACKs. A resposta transporta configuração desejada e comandos pendentes.

Cada comando deve conter:

- `command_uid`
- tipo semântico
- payload versionado
- expiração
- política de execução

A Controller valida localmente:

- compatibilidade do hardware;
- estado operacional;
- intertravamentos;
- revisão esperada;
- duplicidade;
- expiração.

## 5. Política de controle remoto

Permitido na primeira etapa:

- solicitar status;
- enviar configuração desejada;
- parar produção;
- emergência;
- reconhecer alarme quando a condição física normalizou;
- entrar/sair de manutenção;
- reiniciar.

Não permitido inicialmente:

- escrever GPIO arbitrário;
- desabilitar intertravamentos;
- alterar pinagem durante produção;
- iniciar produção remotamente sem habilitação local específica;
- aplicar firmware não assinado.

## 6. Entregas incrementais

### v2.2.0

Identidade, serial obrigatório, hardware manifest, metadados e protocolo de nuvem desativado por padrão.

### v2.2.1

Telemetria HTTPS e status online.

### v2.2.2

Desired/reported configuration e ACK de comandos seguros.

### v2.2.3

Fila offline, rotação de segredo e OTA assinado.