---
name: hm-data-integrity
description: Dados sagrados — backup, migration safety, operações destrutivas, runtime integrity, schema validation, DR plan, compliance, integridade de arquivos. Use antes de shippar projeto que persiste qualquer coisa (DB, files, blob), após mudança em schema/migration, ao definir política de backup, após incidente envolvendo perda de dados, periodicamente em projetos com dados pessoais/financeiros. Cobre nível "produção pessoal" (Electron/Tauri com DB em userData) explicitamente.
---

# /hm-data-integrity — Dados Sagrados (v2)

Você está agora em **modo data integrity**. Seu trabalho e validar que dados do user não sao perdidos. Nem por bug, nem por crash, nem por migration ruim, nem por operação destrutiva acidental, nem por disco morto. Dados sao sagrados — esse princípio precisa de implementação concreta, não só promessa.

## Princípio central

A única perda aceitável de dado e a explicitamente autorizada pelo owner. Tudo o mais é bug. Se dados podem ser perdidos por um comando errado, um crash mal tratado, ou uma migration apressada, o produto não está pronto pra ter usuarios — nem ele mesmo.

## Quando usar

- Antes de shippar projeto que persiste qualquer coisa (DB, files, blob storage)
- Apos mudanca em schema ou migration
- Quando definir política de backup
- Apos qualquer incidente envolvendo perda de dados
- Periodicamente (auditoria de manutencao, especialmente projetos com dados pessoais/financeiros)

## Níveis

| Nível | Quando | Foco |
|---|---|---|
| **Local single-user** | Apps pessoais em dev (CLI local, ferramenta ainda não instalada) | Backup local automático, migration safety, undo de destrutivos |
| **Produção pessoal** | App pessoal instalado (`.app` em /Applications, Tauri/Electron com DB em `userData`, single-user em uso real) | Tudo de local + tratar TODO destrutivo como prod. Sem reset de profile/facts/DB sem confirmacao explícita do user por operação |
| **Multi-user privado** | CRM interno, ferramentas de time | Tudo acima + replicacao, RTO/RPO, audit trail |
| **Produção pública** | SaaS com clientes pagantes | Tudo acima + DR plan, geo-redundancia, compliance (LGPD/GDPR) |

**Produção pessoal e armadilha clássica.** Código roda numa máquina só e parece "dev", mas o DB carrega histórico real e irrecuperavel (notas pessoais, fatos, decisões registradas pelo próprio user). Tratar como prod desde o primeiro `npm run tauri build` / `electron-builder` que vai pra /Applications ou `Program Files`. Regra: qualquer DELETE, sobrescrever DB, reset de profile/facts ou migration não-trivial exige confirmacao explícita do user por operação, mesmo na máquina do dev.

## Dominios

### 1. Backup strategy

| Check | Criterio |
|---|---|
| Backup automático | Existe? Quando dispara (schedule, evento)? |
| Backup atômico | Snapshot consistente, não corrompido por write em curso? (ex: sqlite `.backup`, pg_dump --serializable) |
| Backup criptografado | Em repouso e em transito (se vai pra remoto) |
| Backup versionado | Multiplas gerações. Não só o "último" — histórico |
| Backup testado | Você já restaurou um backup com sucesso? Se não, não tem backup, tem **esperança**. |
| Backup off-site | Pra projetos importantes: copia geografica separada (S3 outra regiao, git remoto, etc) |
| Retention policy | Daily 7d, weekly 4w, monthly 12m? Definido? |

**Patterns:**
- **Single-user app local:** snapshot SQLite no `before-quit` do Electron + commit/push pra repo privado
- **Multi-user:** wal-g pg backups continuous + S3 versioned bucket
- **Files:** rclone sync incremental encrypted

### 2. Migration safety

| Check | Criterio |
|---|---|
| Migrations versionadas | Drizzle, Prisma, Alembic — sequencial, hash-locked |
| Migrations idempotentes | Re-rodar não quebra (auto-migrate na boot) |
| Migrations roll-forward only? | Production = sim. Dev/local = pode roll-back |
| Migration destrutiva exige confirmacao | DROP COLUMN, DROP TABLE — never silent |
| Backup ANTES de migration grande | Auto ou manual? Documentado? |
| Migration testada em copia de prod | Antes de aplicar em prod real |
| Rollback plan documentado | Mesmo que roll-forward only, plano se algo der errado |
| Schema journal sincronizado | Drizzle/Prisma journal bate com estado real do DB? |

**Anti-patterns:**
- ALTER COLUMN sem default/backfill (NOT NULL em coluna nova com rows existentes)
- DROP COLUMN sem etapa intermediaria de read-only
- Migration que demora muito sem `CONCURRENTLY` em indexes (Postgres lock)
- Schema mudou no código sem migration correspondente

### 3. Operações destrutivas

**Lista canonica de operações que EXIGEM confirmacao explícita do owner** (cravada no `~/.claude/CLAUDE.md` global, autorizacao vale apenas pra sessão atual e operação especifica):

- `docker compose down -v` (apaga volumes nomeados — destroi DB)
- `rm -rf` em path não temporario
- `git push --force` em qualquer branch (especial cuidado em main/master)
- `git reset --hard` em branch já publicada
- `git branch -D` ou delete de branch publicada no remote
- `DROP TABLE`, `DROP DATABASE`, `DROP SCHEMA`
- `TRUNCATE` em tabela com dados
- `DELETE` sem `WHERE` especifico
- Mass `UPDATE` sem WHERE
- Kill de processo de produção
- Reset/sobrescrever DB em produção pessoal (ex: SQLite em `userData`/`AppData`)
- Reset de profile/facts/memoria persistente em app pessoal em uso
- Restore de backup que sobrescreve estado atual sem snapshot do atual

**A única exceção:** owner já autorizou EXPLICITAMENTE a operação especifica na sessão atual. Autorizacao não retroage e não se estende a operações parecidas.

| Check | Criterio |
|---|---|
| DELETE sem WHERE bloqueado | ORM raw SQL não executa "DELETE FROM x" sem clause |
| Soft-delete por default | `deleted_at` ao inves de DROP. Hard-delete e exceção auditada |
| Confirmacao explícita pra hard-delete | UI: dialog com nome do objeto. CLI: --force flag |
| Backup automático antes de bulk operation | DROP TABLE, TRUNCATE, mass UPDATE — backup primeiro |
| Audit log de destrutivos | Quem fez, quando, o que removeu |
| Recovery window | Soft-delete fica X dias antes de purge real |
| Owner approval pra ops em prod | Migration prod, mass delete, schema change — owner em loop |
| Produção pessoal tratada como prod | App instalado/em uso com DB em userData = prod. Sem reset sem confirmacao |

**Pattern de confirmacao (CLI):**
```bash
$ tool delete user 123
ERROR: Destructive operation. Add --force to confirm.

$ tool delete user 123 --force
Backing up affected rows to /tmp/backup-...
Deleted 1 user, 47 related records.
```

### 4. Data integrity em runtime

| Check | Criterio |
|---|---|
| Transactions onde atomicidade importa | Multi-table writes em transaction |
| Foreign keys + ON DELETE CASCADE configurado | Sem orphaned records |
| Unique constraints em campos que devem ser únicos | DB enforced, não só app-level |
| NOT NULL em campos obrigatorios | DB enforced |
| Check constraints pra invariantes | `amount >= 0`, `email LIKE '%@%'`, etc |
| Optimistic concurrency em writes simultaneos | `updated_at`/`version` no WHERE de UPDATE |
| Idempotency keys em operações externamente disparadas | Webhook, payment, email send |

### 5. Schema validation runtime (JSON.parse + cast)

| Check | Criterio |
|---|---|
| JSON column tem schema versionado | `payload.schemaVersion` field |
| safeParse via Zod/Pydantic em todo JSON.parse de DB | Sem cast cego |
| Migration de schema versionado documentada | Como fazer v1 → v2 sem perder dados |
| Backwards compat enquanto migra | App lida com v1 E v2 durante transicao |

### 6. Disaster recovery (multi-user / produção)

| Métrica | Definicao | Típico |
|---|---|---|
| **RPO** (Recovery Point Objective) | Quanto dado pode perder? | 5min a 1h dependendo da criticidade |
| **RTO** (Recovery Time Objective) | Quanto tempo pra voltar? | 15min a 4h |
| **Disaster scenarios documentados** | DB corrompido, regiao AWS down, ransomware, dev errou comando | Pelo menos 4 cenarios cobertos |
| **DR drill executado** | Restore real testado em ambiente paralelo | Ao menos 1x/ano |
| **Runbook de recuperacao** | Passo-a-passo escrito | Acessivel mesmo se app down |

### 7. Compliance (se aplicavel — LGPD/GDPR/HIPAA)

| Check | Criterio |
|---|---|
| Right to erasure | User pode pedir exclusao real? Dados removidos de backups apos retention? |
| Right to access | User pode exportar TODOS seus dados em formato legivel? |
| Audit log de acessos | Quem visualizou dados sensíveis (PII, saúde, financeiro)? |
| Breach notification plan | Procedimento de 72h pra ANPD/DPA documentado |
| DPO designado | (LGPD/GDPR) |
| Data minimization | Coleta mínima pro proposito declarado |

### 8. File/blob integrity (se app maneja arquivos)

| Check | Criterio |
|---|---|
| Checksum em uploads | SHA256 calculado e verificado |
| Versioning em blob storage | S3 versioned bucket pra recovery de overwrite acidental |
| Lifecycle policy | Auto-archive pra cold storage apos N dias |
| Object lock em arquivos criticos | Imutabilidade WORM pra compliance/legal |
| Backup de blob storage | S3 cross-region replication ou snapshot externo |

### 9. Observabilidade pra detectar problemas cedo

- Alerta quando backup falha
- Alerta quando DB size cresce muito rapido (potencial bug ou ataque)
- Alerta quando query lenta (indica index missing)
- Alerta quando rate de DELETE alto (indica bug ou ataque)
- Dashboard com volume de dados, último backup, tamanho dos backups

## Output

```
DATA INTEGRITY AUDIT
Projeto: [nome]
Nível aplicado: [Local / Multi-user / Produção pública]
Volume estimado: [rows/files, tamanho]

DOMÍNIO 1: BACKUP
[Check]: PASS/FAIL — detalhes + fix se FAIL

DOMÍNIO 2: MIGRATION
[Check]: PASS/FAIL

DOMÍNIO 3: DESTRUTIVAS
[Check]: PASS/FAIL

DOMÍNIO 4: RUNTIME INTEGRITY
[Check]: PASS/FAIL

DOMÍNIO 5: SCHEMA VALIDATION
[Check]: PASS/FAIL

DOMÍNIO 6: DR (se Multi-user/Produção)
RPO atual: [valor]
RTO atual: [valor]
Drill executado: [data último / nunca]

DOMÍNIO 7: COMPLIANCE (se aplicavel)
[Check]: PASS/FAIL

DOMÍNIO 8: FILES (se aplicavel)
[Check]: PASS/FAIL

DOMÍNIO 9: OBSERVABILIDADE
[Check]: PASS/FAIL

VEREDICTO
Dados protegidos / EM RISCO — X criticos pra resolver primeiro
```

## Regras

- **Toda perda potencial de dado é CRÍTICO.** Sem MEDIO. Sem BAIXO.
- Backup que nunca foi restaurado não é backup. Se nunca testou, marca FAIL.
- Migration sem rollback plan é CRÍTICO em produção.
- DELETE sem confirmacao em CLI/UI público = CRÍTICO.
- Disco morto e cenario OBRIGATÓRIO em DR plan.
- Owner aprova política de retention. Default conservador: não apagar nada que pode ser útil.
- Se projeto e single-user local: backup automático no quit + commit pra repo privado e baseline mínimo.
- **Produção pessoal não é dev.** App instalado em /Applications + DB em `userData` (Tauri/Electron) = produção. Confirmacao explícita por operação destrutiva, sem exceção.
- Compliance falha = não shippa pra mercado regulado. Sem negociacao.