[leandrotcawork]

A lista de permissões do banco do Hub para "O Sync de qualquer conector", num pull request só dela, como manda data D11 e a ordem do cartão (docs/steps/o-sync-de-qualquer-conector.md, "A ordem"). Precisa da palavra do fundador para entrar.

O que muda no banco do Hub

Três tabelas novas no esquema copies, cada uma com a coluna da empresa e a política por linha (decisão 0039), e uma coluna:

Objeto	Para quê	O que o login do Hub (hub_company) pode
copies.copy_source	Cada conta do conector de uma cópia lembra onde parou: a passada, a posição, a marca e até quando o fornecedor pediu para esperar	ler, inserir; mudar só pass, pass_started_at, position, watermark, wait_until; nunca apagar (sai pela cascata da conexão ou da cópia)
copies.copy_table_left	A tabela de uma cópia que acabou enquanto o banco da empresa estava calado, para ser apagada no próximo Desligar ou Ligar	ler, inserir, apagar (a linha sai depois do DROP TABLE)
copies.copy_proposal_source	As contas de uma proposta de cópia do Builder	ler, inserir; sai pela cascata
copies.copy_proposal.proved_calls	As chamadas que uma passada inteira gasta, mostradas no cartão da proposta	coberta pelo INSERT que já existe
copies.copy	—	passa a poder apagar

O último item vai além das tabelas novas e precisa ser dito: pela decisão C da página ("Não, beleza, eu concordo"), a cópia acaba no mesmo instante em que sai a sua última conta. O construtor da U3 escolheu fazer isso em TypeScript, na mesma transação que apaga a conexão (DELETE … RETURNING das cópias sem fonte, sob a trava delas), e não com um gatilho escondido no banco (data D16). Para isso o login do Hub precisa de DELETE em copies.copy. A cascata de hoje já levava as rodadas e as liberações da cópia; continua igual.

copy_table_left é drenada com DELETE … RETURNING na transação do Hub que segura a linha até o DROP terminar, e não com SELECT … FOR UPDATE SKIP LOCKED: FOR UPDATE exige UPDATE em alguma coluna, que a tabela não precisa (medido no PostgreSQL 18: permission denied com só SELECT, INSERT, DELETE). O efeito pedido pela tabela de falhas fica: dois drenos nunca apagam a mesma tabela duas vezes, e um Ligar que acha a linha travada espera.

Arquivos

• apps/server/src/hub/copies/tables.ts: as três tabelas e a coluna.
• apps/server/migrations/20261111234347_sync_copy_sources/: a migração gerada pelo drizzle-kit.
• apps/server/migrations/20261111234429_sync_copy_sources_grants/: as permissões, SQL escrito à mão (data D5).
• apps/server/database-grants.sql: o instantâneo aprovado.

Nada lê nem escreve as tabelas novas ainda: a U3 (o motor) e a U4 (o Builder) chegam no pull request de construção seguinte. A migração que dá a cada cópia de hoje a sua fonte e a que tira copy_connection_fkey são da U3.

O que rodou

• catalog.test.ts e migrate.test.ts num PostgreSQL 18 local, no formato do CI: 35 passaram, 0 falharam.
• npm run migrations -- --base origin/main: ok.
• tsc de apps/server: ok. npm run docs: ok.