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 temporariogit push --force em qualquer branch (especial cuidado em main/master)git reset --hard em branch já publicadagit branch -D ou delete de branch publicada no remoteDROP TABLE, DROP DATABASE, DROP SCHEMATRUNCATE em tabela com dadosDELETE 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):
$ 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.
By