/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.
Source: rodrigohighermind/highermind-code-skills — distributed by TomeVault.
1---2name: hm-data-integrity3description: 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. Use when this capability is needed.4---56# /hm-data-integrity — Dados Sagrados (v2)78Você 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.910## Princípio central1112A ú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.1314## Quando usar1516- Antes de shippar projeto que persiste qualquer coisa (DB, files, blob storage)17- Apos mudanca em schema ou migration18- Quando definir política de backup19- Apos qualquer incidente envolvendo perda de dados20- Periodicamente (auditoria de manutencao, especialmente projetos com dados pessoais/financeiros)2122## Níveis2324| Nível | Quando | Foco |25|---|---|---|26| **Local single-user** | Apps pessoais em dev (CLI local, ferramenta ainda não instalada) | Backup local automático, migration safety, undo de destrutivos |27| **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 |28| **Multi-user privado** | CRM interno, ferramentas de time | Tudo acima + replicacao, RTO/RPO, audit trail |29| **Produção pública** | SaaS com clientes pagantes | Tudo acima + DR plan, geo-redundancia, compliance (LGPD/GDPR) |3031**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.3233## Dominios3435### 1. Backup strategy3637| Check | Criterio |38|---|---|39| Backup automático | Existe? Quando dispara (schedule, evento)? |40| Backup atômico | Snapshot consistente, não corrompido por write em curso? (ex: sqlite `.backup`, pg_dump --serializable) |41| Backup criptografado | Em repouso e em transito (se vai pra remoto) |42| Backup versionado | Multiplas gerações. Não só o "último" — histórico |43| Backup testado | Você já restaurou um backup com sucesso? Se não, não tem backup, tem **esperança**. |44| Backup off-site | Pra projetos importantes: copia geografica separada (S3 outra regiao, git remoto, etc) |45| Retention policy | Daily 7d, weekly 4w, monthly 12m? Definido? |4647**Patterns:**48- **Single-user app local:** snapshot SQLite no `before-quit` do Electron + commit/push pra repo privado49- **Multi-user:** wal-g pg backups continuous + S3 versioned bucket50- **Files:** rclone sync incremental encrypted5152### 2. Migration safety5354| Check | Criterio |55|---|---|56| Migrations versionadas | Drizzle, Prisma, Alembic — sequencial, hash-locked |57| Migrations idempotentes | Re-rodar não quebra (auto-migrate na boot) |58| Migrations roll-forward only? | Production = sim. Dev/local = pode roll-back |59| Migration destrutiva exige confirmacao | DROP COLUMN, DROP TABLE — never silent |60| Backup ANTES de migration grande | Auto ou manual? Documentado? |61| Migration testada em copia de prod | Antes de aplicar em prod real |62| Rollback plan documentado | Mesmo que roll-forward only, plano se algo der errado |63| Schema journal sincronizado | Drizzle/Prisma journal bate com estado real do DB? |6465**Anti-patterns:**66- ALTER COLUMN sem default/backfill (NOT NULL em coluna nova com rows existentes)67- DROP COLUMN sem etapa intermediaria de read-only68- Migration que demora muito sem `CONCURRENTLY` em indexes (Postgres lock)69- Schema mudou no código sem migration correspondente7071### 3. Operações destrutivas7273**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):7475- `docker compose down -v` (apaga volumes nomeados — destroi DB)76- `rm -rf` em path não temporario77- `git push --force` em qualquer branch (especial cuidado em main/master)78- `git reset --hard` em branch já publicada79- `git branch -D` ou delete de branch publicada no remote80- `DROP TABLE`, `DROP DATABASE`, `DROP SCHEMA`81- `TRUNCATE` em tabela com dados82- `DELETE` sem `WHERE` especifico83- Mass `UPDATE` sem WHERE84- Kill de processo de produção85- Reset/sobrescrever DB em produção pessoal (ex: SQLite em `userData`/`AppData`)86- Reset de profile/facts/memoria persistente em app pessoal em uso87- Restore de backup que sobrescreve estado atual sem snapshot do atual8889**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.9091| Check | Criterio |92|---|---|93| DELETE sem WHERE bloqueado | ORM raw SQL não executa "DELETE FROM x" sem clause |94| Soft-delete por default | `deleted_at` ao inves de DROP. Hard-delete e exceção auditada |95| Confirmacao explícita pra hard-delete | UI: dialog com nome do objeto. CLI: --force flag |96| Backup automático antes de bulk operation | DROP TABLE, TRUNCATE, mass UPDATE — backup primeiro |97| Audit log de destrutivos | Quem fez, quando, o que removeu |98| Recovery window | Soft-delete fica X dias antes de purge real |99| Owner approval pra ops em prod | Migration prod, mass delete, schema change — owner em loop |100| Produção pessoal tratada como prod | App instalado/em uso com DB em userData = prod. Sem reset sem confirmacao |101102**Pattern de confirmacao (CLI):**103```bash104$ tool delete user 123105ERROR: Destructive operation. Add --force to confirm.106107$ tool delete user 123 --force108Backing up affected rows to /tmp/backup-...109Deleted 1 user, 47 related records.110```111112### 4. Data integrity em runtime113114| Check | Criterio |115|---|---|116| Transactions onde atomicidade importa | Multi-table writes em transaction |117| Foreign keys + ON DELETE CASCADE configurado | Sem orphaned records |118| Unique constraints em campos que devem ser únicos | DB enforced, não só app-level |119| NOT NULL em campos obrigatorios | DB enforced |120| Check constraints pra invariantes | `amount >= 0`, `email LIKE '%@%'`, etc |121| Optimistic concurrency em writes simultaneos | `updated_at`/`version` no WHERE de UPDATE |122| Idempotency keys em operações externamente disparadas | Webhook, payment, email send |123124### 5. Schema validation runtime (JSON.parse + cast)125126| Check | Criterio |127|---|---|128| JSON column tem schema versionado | `payload.schemaVersion` field |129| safeParse via Zod/Pydantic em todo JSON.parse de DB | Sem cast cego |130| Migration de schema versionado documentada | Como fazer v1 → v2 sem perder dados |131| Backwards compat enquanto migra | App lida com v1 E v2 durante transicao |132133### 6. Disaster recovery (multi-user / produção)134135| Métrica | Definicao | Típico |136|---|---|---|137| **RPO** (Recovery Point Objective) | Quanto dado pode perder? | 5min a 1h dependendo da criticidade |138| **RTO** (Recovery Time Objective) | Quanto tempo pra voltar? | 15min a 4h |139| **Disaster scenarios documentados** | DB corrompido, regiao AWS down, ransomware, dev errou comando | Pelo menos 4 cenarios cobertos |140| **DR drill executado** | Restore real testado em ambiente paralelo | Ao menos 1x/ano |141| **Runbook de recuperacao** | Passo-a-passo escrito | Acessivel mesmo se app down |142143### 7. Compliance (se aplicavel — LGPD/GDPR/HIPAA)144145| Check | Criterio |146|---|---|147| Right to erasure | User pode pedir exclusao real? Dados removidos de backups apos retention? |148| Right to access | User pode exportar TODOS seus dados em formato legivel? |149| Audit log de acessos | Quem visualizou dados sensíveis (PII, saúde, financeiro)? |150| Breach notification plan | Procedimento de 72h pra ANPD/DPA documentado |151| DPO designado | (LGPD/GDPR) |152| Data minimization | Coleta mínima pro proposito declarado |153154### 8. File/blob integrity (se app maneja arquivos)155156| Check | Criterio |157|---|---|158| Checksum em uploads | SHA256 calculado e verificado |159| Versioning em blob storage | S3 versioned bucket pra recovery de overwrite acidental |160| Lifecycle policy | Auto-archive pra cold storage apos N dias |161| Object lock em arquivos criticos | Imutabilidade WORM pra compliance/legal |162| Backup de blob storage | S3 cross-region replication ou snapshot externo |163164### 9. Observabilidade pra detectar problemas cedo165166- Alerta quando backup falha167- Alerta quando DB size cresce muito rapido (potencial bug ou ataque)168- Alerta quando query lenta (indica index missing)169- Alerta quando rate de DELETE alto (indica bug ou ataque)170- Dashboard com volume de dados, último backup, tamanho dos backups171172## Output173174```175DATA INTEGRITY AUDIT176Projeto: [nome]177Nível aplicado: [Local / Multi-user / Produção pública]178Volume estimado: [rows/files, tamanho]179180DOMÍNIO 1: BACKUP181[Check]: PASS/FAIL — detalhes + fix se FAIL182183DOMÍNIO 2: MIGRATION184[Check]: PASS/FAIL185186DOMÍNIO 3: DESTRUTIVAS187[Check]: PASS/FAIL188189DOMÍNIO 4: RUNTIME INTEGRITY190[Check]: PASS/FAIL191192DOMÍNIO 5: SCHEMA VALIDATION193[Check]: PASS/FAIL194195DOMÍNIO 6: DR (se Multi-user/Produção)196RPO atual: [valor]197RTO atual: [valor]198Drill executado: [data último / nunca]199200DOMÍNIO 7: COMPLIANCE (se aplicavel)201[Check]: PASS/FAIL202203DOMÍNIO 8: FILES (se aplicavel)204[Check]: PASS/FAIL205206DOMÍNIO 9: OBSERVABILIDADE207[Check]: PASS/FAIL208209VEREDICTO210Dados protegidos / EM RISCO — X criticos pra resolver primeiro211```212213## Regras214215- **Toda perda potencial de dado é CRÍTICO.** Sem MEDIO. Sem BAIXO.216- Backup que nunca foi restaurado não é backup. Se nunca testou, marca FAIL.217- Migration sem rollback plan é CRÍTICO em produção.218- DELETE sem confirmacao em CLI/UI público = CRÍTICO.219- Disco morto e cenario OBRIGATÓRIO em DR plan.220- Owner aprova política de retention. Default conservador: não apagar nada que pode ser útil.221- Se projeto e single-user local: backup automático no quit + commit pra repo privado e baseline mínimo.222- **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.223- Compliance falha = não shippa pra mercado regulado. Sem negociacao.224225---226> Source: [rodrigohighermind/highermind-code-skills](https://github.com/rodrigohighermind/highermind-code-skills) — distributed by [TomeVault](https://tomevault.io).227<!-- tomevault:4.0:skill_md:2026-07-04 -->
tomevault-io