Requisição 194 — Hotfix: migrações obsoletas no ambiente em execução

Origem: Humano, 2026-09-29 — o pipeline do [REDACTED] travou duas vezes com Duplicate migration: uma migração renomeada deixava a cópia antiga no servidor e o Phinx recusava todas…

Origem: Humano, 2026-09-29 — o pipeline do [REDACTED] travou duas vezes com Duplicate migration: uma migração renomeada deixava a cópia antiga no servidor e o Phinx recusava todas as execuções seguintes (para todos os agentes que usam o Lab). Lote Vinculado: BATCH-198. Status: implementada.

Pedido

Antes de aplicar o pacote (deploy de projeto por API e atualização do sistema), limpar as migrações que estão no servidor. A limpeza acontece no ambiente em execução, nunca no repositório.

Decisão de desenho

db/migrations no servidor tem dois donos: o core (atualização do sistema, sync do core) e o projeto (deploy por API, pipeline por rsync). O pacote de um não traz as migrações do outro, então apagar a pasta inteira antes de extrair apagaria as do outro dono. A limpeza é por dono:

cada entrega grava db/.c2f-migrations-<core|projeto>.json com a lista completa que entregou;
o que o mesmo dono entregou antes e não entrega mais sai;
a cópia antiga de uma migração renomeada (mesma classe, outro nome) sai, inclusive na primeira vez;
mesma versão com classe diferente, ou arquivo que consta do manifesto do outro dono, é choque: nada é apagado, o choque vai para o log (o projeto pode sobrepor o core; o conflito é registrado, não resolvido às cegas).

Itens

gestor/controladores/atualizacoes/atualizacoes-migracoes.php (novo): regra acima + uso por CLI.
api.php (api_project_update): limpeza antes da cópia; resposta traz migrations (removidas, choques, log).
atualizacoes-sistema.php: limpeza do dono core antes de mover o staging, no fluxo CLI e no web.
deploy-project-v2.sh: o pacote leva o manifesto completo do projeto (também no gitDeploy, que só manda o que mudou).
synchronize-project.sh (--migrations-only) e project:update-all: limpeza no destino antes da etapa 2 (banco), que roda antes da etapa de arquivos.

Critérios de aceite

Migração renomeada não deixa cópia antiga no servidor em nenhum dos três caminhos.
Migrações do outro dono nunca são apagadas; choques aparecem no log.
AtualizacoesMigracoesTest verde; pipeline do Lab volta a passar sem intervenção manual no servidor.

Fora do escopo (backlog)

Exclusão de dados, controle de choques de arquivos core × projeto × plugin, backup e rollback: BL-028.

# Requisição 194 — Hotfix: migrações obsoletas no ambiente em execução
**Origem**: Humano, 2026-09-29 — o pipeline do `[REDACTED]` travou duas vezes com `Duplicate migration`: uma migração renomeada deixava a cópia antiga no servidor e o Phinx recusava todas as execuções seguintes (para todos os agentes que usam o Lab).
**Lote Vinculado**: `BATCH-198`.
**Status**: implementada.
---
## Pedido
Antes de aplicar o pacote (deploy de projeto por API e atualização do sistema), limpar as migrações que estão no servidor. A limpeza acontece **no ambiente em execução**, nunca no repositório.
## Decisão de desenho
`db/migrations` no servidor tem **dois donos**: o core (atualização do sistema, sync do core) e o projeto (deploy por API, pipeline por rsync). O pacote de um não traz as migrações do outro, então apagar a pasta inteira antes de extrair apagaria as do outro dono. A limpeza é **por dono**:
1. cada entrega grava `db/.c2f-migrations-<core|projeto>.json` com a lista completa que entregou;
2. o que o mesmo dono entregou antes e não entrega mais sai;
3. a cópia antiga de uma migração renomeada (mesma classe, outro nome) sai, inclusive na primeira vez;
4. mesma versão com classe diferente, ou arquivo que consta do manifesto do outro dono, é **choque**: nada é apagado, o choque vai para o log (o projeto pode sobrepor o core; o conflito é registrado, não resolvido às cegas).
## Itens
1. `gestor/controladores/atualizacoes/atualizacoes-migracoes.php` (novo): regra acima + uso por CLI.
2. `api.php` (`api_project_update`): limpeza antes da cópia; resposta traz `migrations` (removidas, choques, log).
3. `atualizacoes-sistema.php`: limpeza do dono `core` antes de mover o staging, no fluxo CLI e no web.
4. `deploy-project-v2.sh`: o pacote leva o manifesto completo do projeto (também no `gitDeploy`, que só manda o que mudou).
5. `synchronize-project.sh` (`--migrations-only`) e `project:update-all`: limpeza no destino antes da etapa 2 (banco), que roda antes da etapa de arquivos.
## Critérios de aceite
1. Migração renomeada não deixa cópia antiga no servidor em nenhum dos três caminhos.
2. Migrações do outro dono nunca são apagadas; choques aparecem no log.
3. `AtualizacoesMigracoesTest` verde; pipeline do Lab volta a passar sem intervenção manual no servidor.
## Fora do escopo (backlog)
Exclusão de dados, controle de choques de arquivos core × projeto × plugin, backup e rollback: [BL-028](../../backlog/BL-028-atualizacao-segura-choques-backup-rollback.md).