# Merge entre sessões paralelas.
#
# O conflito que mais custa neste repo não é o do CHANGELOG (o git auto-mescla
# aquele: medido entre os PRs #354 e #349, `git merge-file` sai com 0). É o dos
# dois arquivos append-only que TODA migration toca — e neles os dois lados
# estão sempre certos: cada sessão acrescentou a sua linha no fim.

# `union` = fica com os dois lados, sem marcador. Para uma tabela de registro,
# é a resolução que um humano faria à mão em 100% dos casos.
supabase/migrations/MANIFEST.md merge=union

# ─── E por que `supabase/baseline.sql` NÃO está aqui ────────────────────────
#
# Porque `union` nele é pior que o conflito. Medido num merge real seguido de
# aplicação num Postgres 17: o merge sai LIMPO (exit 0, "Merge made by the
# 'ort' strategy", zero marcadores) e o SQL resultante intercala duas funções —
# uma declarada e nunca definida, a outra com o corpo da primeira. Aí:
#
#   - no `install.sh` (banco novo, ON_ERROR_STOP=1) morre com syntax error;
#   - no `update.sh` do CLIENTE (sem ON_ERROR_STOP) sai com codigo 0, deixando
#     zero funções criadas e engolindo o resto do arquivo em silêncio.
#
# O marcador de conflito, aqui, é FEATURE: ele é a única coisa que obriga
# alguém a olhar antes de o arquivo chegar à VPS de um cliente. `merge=binary`
# tem o mesmo defeito pelo outro lado (fica com "ours" e um `git add` descarta
# o outro lado sem ninguém ver).
#
# O conserto certo para o baseline é de processo, não de atributo: apêndice
# idempotente por migration, como a doutrina de migrations do CLAUDE.md manda.
