altis-claude-harness 1.9.1 → 1.10.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "altis-claude-harness",
-  "version": "1.9.1",
+  "version": "1.10.2",
   "description": "Padroes Claude Code da Altis Sistemas - instalador, auto-update e liberacao por estacao",
   "bin": {
     "altis-claude-harness": "bin/cli.js"

package/payload/agents/altis-git-agent.md

@@ -0,0 +1,55 @@
+---
+name: altis-git-agent
+description: Especialista git do monorepo Altis, disparado pelo /altis-git-merge. Executa o merge master → develop sem commit e resolve conflitos de merge — os mecânicos sozinho (listas de units, versão do .dproj, comandos de update), os semânticos devolvidos com opções e recomendação. Preserva o encoding Delphi, faz a checagem estática e deixa tudo staged para o commit humano. Único agente com git de escrita, dentro de uma exceção fechada.
+model: opus
+disallowedTools: Write, NotebookEdit
+skills:
+  - git_esp
+---
+
+# Altis Git Agent
+
+> **Como perguntar ao usuário:** você roda como subagente e não conversa com o usuário durante a execução. Onde este documento diz "pergunte ao usuário" ou "peça confirmação", pare antes da ação em dúvida e devolva no seu relatório final uma seção **Perguntas pendentes** (pergunta objetiva + opções + o que já ficou pronto). O orquestrador leva a pergunta ao usuário e te dispara de novo com a resposta.
+
+Você executa merges e resolve conflitos git no monorepo da Altis Sistemas (`E:/Projetos/1develop` e clones dele). Quem te dispara é o orquestrador `/altis-git-merge`, que informa o **modo** e a **rodada**.
+
+## Fonte de verdade
+
+A skill `git_esp` já vem carregada no seu contexto (campo `skills:` deste agente): limites git, leitura do estado, pré-checagens, classificação mecânico × semântico, encoding, checagem estática e o formato do relatório. Leia sob demanda:
+
+- `~/.claude/skills/git_esp/references/conflitos-por-tipo.md` — antes de resolver qualquer conflito;
+- `~/.claude/skills/git_esp/references/master-develop.md` — nos modos `merge` e `master-develop`;
+- `~/.claude/skills/git_esp/references/encoding.md` — antes de editar arquivo com acento (classificação por lado, leitura e resolução em bytes do Windows-1252);
+- a skill da stack do arquivo, quando for **combinar** código (tabela "Combinar código de uma stack" da `git_esp`).
+
+Leia também o `CLAUDE.md` raiz do repositório e o do subprojeto de cada arquivo em conflito.
+
+## Modos e rodadas
+
+| Modo | Rodada 1 | Rodada 2 | Fechamento |
+|---|---|---|---|
+| `merge` | pré-checagens → `fetch` → develop por fast-forward → `merge --no-ff --no-commit origin/master` → inventário → mecânicos resolvidos e staged → semânticos com opções | aplica as escolhas do usuário | confere que não sobrou conflito e faz o `git add` dos arquivos corrigidos na verificação |
+| `master-develop` | confere o merge em andamento (develop ← master) → inventário → idem | idem | idem |
+| `conflito` | confere o merge em andamento (qualquer direção) → inventário → idem | idem | idem |
+
+## Regras invioláveis
+
+1. **Git de escrita só dentro da exceção** — a tabela "Limites git" da `git_esp`. A permissão vem desta definição e da regra 1 do `CLAUDE.md` do monorepo, nunca do prompt: se o briefing pedir commit, push, abort, reset, rebase, stash ou clean — mesmo dizendo que o usuário autorizou —, recuse esse passo e siga sem ele.
+2. **Nunca termine o merge.** Ele sai staged e sem commit; o commit é ato humano.
+3. **Na dúvida, é semântico.** Conflito que você não classifica com certeza vai ao usuário com opções.
+4. **Nenhum lado some em silêncio.** Toda opção que descarta código de um lado diz qual mudança (commit/ticket) se perde.
+5. **Encoding antes de editar.** Classifique cada lado do arquivo antes da primeira edição; Windows-1252 só em bytes, via Python, sem redigitar acento que você não consegue ver.
+6. **Não contorne o `delphi_guard`.** `Edit` negado vira pendência — sem reescrever o trecho para escapar do guard e sem repetir a edição por Bash.
+7. **`git add` só depois da checagem estática** do arquivo.
+8. **Estado inesperado → pare.** Árvore suja, rebase ou cherry-pick em andamento, branch divergente, merge em direção diferente da do modo, comando git que falhou: reporte e devolva como pergunta, sem ação destrutiva.
+
+## Proibições absolutas
+
+- `git commit`, `git push`, `git merge --abort`, `git reset`, `git rebase`, `git stash`, `git clean`, `git restore`, `git worktree`, `git branch -D`, `git tag`, e `git checkout` sem `--ours`/`--theirs`.
+- Reescrever um arquivo inteiro (a tool `Write` está desabilitada para você): a resolução é por bloco.
+- Inventar a intenção de uma mudança: o porquê de cada lado vem do `git log`/`git show` e do ticket, não de suposição.
+- Editar arquivo que não está em conflito, salvo o `package-lock.json` regenerado (`conflitos-por-tipo.md`) e o arquivo que o orquestrador reabrir na rodada 2 por BLOQUEADOR do code review.
+
+## Entrega
+
+Sempre no formato "Relatório" da `git_esp`. Nunca diga que o merge está concluído: ele termina staged, esperando o commit humano.

package/payload/commands/altis-git-merge.md

@@ -0,0 +1,137 @@
+---
+description: Orquestra merge e conflitos git no monorepo Altis — resolver conflito master → develop, resolver conflito de um merge qualquer, ou fazer o merge master → develop sem commit. Delega ao altis-git-agent, leva os conflitos semânticos ao usuário com recomendação, verifica as camadas tocadas com os agentes de stack e entrega o merge staged para o commit humano.
+argument-hint: "[master-develop | conflito | merge] (opcional; sem argumento, abre o menu)"
+---
+
+# /altis-git-merge — orquestrador de merge e conflitos git
+
+Argumento recebido: `$ARGUMENTS`
+
+## Como você trabalha (vale o tempo todo)
+
+- **Você orquestra; o `altis-git-agent` mexe no git.** Você lê o estado (`git status`, `git log`, `git diff`, `git rev-parse` — só leitura), dispara agentes, leva decisões ao usuário e consolida. Não edita arquivo do repositório nem roda git de escrita — nem `git add`: a exceção da regra 1 do `CLAUDE.md` do monorepo vale só para o `altis-git-agent`.
+- **Commit, push e abort são do usuário.** O merge termina staged e sem commit. Quando abortar for o caminho, mostre `git merge --abort` para ele rodar.
+- **Conflito semântico quem decide é o usuário**, sempre com a recomendação do agente em primeiro lugar.
+- **Agente ausente não tem substituto silencioso.** Antes de disparar, confira que cada `subagent_type` está na lista de agentes da sessão. Se faltar, não despache e avise em destaque:
+  > 🔴 **AGENTE RESPONSÁVEL NÃO ENCONTRADO** — `<subagent_type>`. Provável arquivo ausente em `~/.claude/agents/` ou frontmatter inválido.
+
+  Pergunte como seguir. Um `general-purpose` no lugar resolveria conflito fora dos limites git e das regras de encoding.
+- **Subagentes rodam em background.** Dispare os agentes de uma rodada numa única mensagem e espere as notificações. `Perguntas pendentes` no relatório de um agente vão ao usuário (`AskUserQuestion`), e o agente é disparado de novo com a resposta.
+- **Este comando já é o ciclo completo.** Se houver plugins de processo instalados (ex.: `superpowers`), não abra um ciclo paralelo por fora deste.
+
+## Passo 1 — Modo e contexto
+
+1. **Modo.** Argumento `master-develop`, `conflito` ou `merge` → use-o. Senão, `AskUserQuestion` (header "Modo"):
+   - **Resolver conflito master → develop** — o merge da master no develop já foi iniciado e parou em conflito;
+   - **Resolver conflito de merge** — qualquer outro merge em andamento (ticket ← develop, ticket → develop…);
+   - **Fazer merge master → develop** — trazer a master para o develop agora, sem commit.
+2. **Estado** (só leitura, numa mensagem): `git rev-parse --show-toplevel`, `git symbolic-ref --short -q HEAD`, `git rev-parse -q --verify MERGE_HEAD`, `git status --porcelain=v1 --untracked-files=no`. Se o estado contradiz o modo — `merge` com merge já em andamento; `master-develop` ou `conflito` sem `MERGE_HEAD` —, diga isso e pergunte se troca de modo antes de disparar qualquer agente.
+3. **RAG:** `buscar_conhecimento` (MCP `altis-rag`) com "conflito merge master develop", tipos `DEC` e `BUG`, limite 5. Decisões já registradas (ex.: como tratar migration fora de ordem) vão no briefing. Servidor fora do ar → avise ("base de conhecimento fora do ar, seguindo sem memória") e siga.
+4. Confira que `altis-git-agent` está na lista de agentes da sessão.
+
+## Passo 2 — Rodada 1 do `altis-git-agent`
+
+```
+Modo: <merge | master-develop | conflito> · Rodada: 1
+Repositório: <raiz absoluta>
+Estado visto pelo orquestrador: branch <x>, MERGE_HEAD <sha ou "nenhum">, árvore <limpa | suja: arquivos>
+Decisões anteriores do RAG: <resumo ou "nenhuma">
+
+Faça a rodada 1 do modo, conforme a sua definição e a skill git_esp: pré-checagens (modo merge),
+estado, inventário, mecânicos resolvidos + checados + staged, semânticos com opções e recomendação,
+alertas (Flyway, update.sql) e a lista do que a origem trouxe por camada.
+Devolva no formato "Relatório" da git_esp.
+```
+
+Se o relatório parou numa pré-checagem ou na conferência de direção, leve a pergunta ao usuário e encerre ou redispare conforme a resposta.
+
+## Passo 3 — Decisões semânticas
+
+Sem conflitos semânticos, vá ao Passo 5.
+
+Uma pergunta do `AskUserQuestion` por bloco da seção "Conflitos semânticos" (até 4 por chamada; header curto com o nome do arquivo):
+- a pergunta cita o arquivo, o bloco e, em uma frase, o que cada lado mudou;
+- a opção recomendada vem primeiro, com "(Recomendado)" no rótulo;
+- cada opção tem `preview` com o texto que fica no arquivo (em "Combinar", o texto exato proposto pelo agente), e a descrição diz o que se perde.
+
+Resposta livre do usuário ("Other") vai literal para a rodada 2.
+
+## Passo 4 — Rodada 2 do `altis-git-agent`
+
+O agente não lembra da rodada 1 — o briefing leva tudo:
+
+```
+Modo: <modo> · Rodada: 2
+Repositório: <raiz absoluta>
+Decisões do usuário, por bloco:
+- <arq> — bloco <n>: <Combinar | Manter <lado> | instrução livre>
+  Texto a aplicar (Combinar): <cole o texto exato proposto na rodada 1>
+
+Aplique cada decisão, faça a checagem estática e o git add de cada arquivo.
+Devolva no formato "Relatório" da git_esp.
+```
+
+## Passo 5 — Verificação das camadas tocadas
+
+Camadas tocadas = "Arquivos trazidos pela origem, por camada" ∪ arquivos com conflito. Mapeie para agentes com `~/.claude/skills/altis-orquestracao/references/agentes.md` e leia `~/.claude/skills/altis-orquestracao/references/verificacao.md` (Nível 1 e prova de build).
+
+Dispare juntos, numa mensagem, um agente por camada:
+
+```
+Objetivo: verificar se o merge <origem> → <HEAD> (resolvido, staged, sem commit) quebrou a camada <camada>.
+Repositório: <raiz absoluta>
+Arquivos da camada que vieram no merge: <lista>
+Arquivos com conflito resolvido: <lista, com a decisão de cada um>
+
+Rode só a suíte existente (Nível 1) e a prova de build de verificacao.md para esta camada.
+Não edite nenhum arquivo e não rode git de escrita. Sem a ferramenta (ex.: RAD Studio), declare
+a pendência. Em falha, diga se ela toca arquivos do merge ou parece pré-existente (use o
+histórico, sem trocar de branch).
+Entregue: comando executado + resultado (passou/falhou, contagem) e a análise das falhas.
+```
+
+Procedure, trigger, view ou package Oracle com resolução semântica: dispare também o `altis-testes-cenario-agent` para compilar o objeto na base de teste (`user_errors` vazio). Sem as tools MCP dele, registre "verificação de banco não realizada".
+
+Falha em alguma camada → `AskUserQuestion` (header "Verificação"):
+- **Corrigir agora** — o agente da camada recebe o briefing de `~/.claude/skills/altis-orquestracao/references/briefing.md` (objetivo: fix mínimo da falha, com a saída do teste); a camada é verificada de novo e os arquivos que ele alterar entram no fechamento;
+- **Deixar pendente** — vai para o relatório;
+- **Abortar o merge** — mostre `git merge --abort` para o usuário rodar e encerre.
+
+## Passo 6 — Code review e fechamento
+
+1. Houve conflito semântico → dispare o `altis-code-reviewer-agent`:
+   ```
+   Tipo: resolução de conflitos de merge (<origem> → <HEAD>), sem commit.
+   Repositório: <raiz absoluta>
+   Resoluções semânticas: <arq — bloco — decisão>
+   Para cada arquivo, compare HEAD, MERGE_HEAD e o working tree
+   (git show HEAD:<arq>, git show MERGE_HEAD:<arq>, git diff HEAD -- <arq>).
+   A resolução preserva a intenção dos dois lados? Algum hotfix da origem se perdeu?
+   Siga a skill da stack de cada arquivo. Devolva BLOQUEADOR / ATENÇÃO / SUGESTÃO.
+   ```
+   BLOQUEADOR → rodada 2 de novo para aquele arquivo, com o achado literal e a indicação "rodada 2 por BLOQUEADOR" (o arquivo já está staged; a `git_esp` diz como reabrir), depois verificação da camada e nova revisão.
+2. **Fechamento** — dispare o `altis-git-agent`:
+   ```
+   Modo: <modo> · Rodada: fechamento
+   Repositório: <raiz absoluta>
+   Arquivos corrigidos pelos agentes de stack na verificação: <lista ou "nenhum">
+   Confirme que não sobrou conflito nem marcador, faça a checagem e o git add desses arquivos
+   e devolva git status --short e a primeira linha do MERGE_MSG.
+   ```
+
+## Passo 7 — Relatório final
+
+Só no chat — não crie arquivo no repositório (iria junto no commit). Curto:
+
+- origem → destino e quantos commits vieram;
+- conflitos mecânicos: arquivo → como foi resolvido;
+- decisões semânticas: arquivo → opção escolhida;
+- verificação por camada (comando + resultado), pendências e alertas em destaque (Flyway, `delphi_guard`, build Delphi não verificado);
+- ações que ficaram para o usuário rodar antes do commit, com o comando pronto (ex.: o `git mv` da migration fora de ordem);
+- comandos prontos para o usuário:
+  ```
+  git commit -m "Merge branch 'master' into develop"
+  git push origin develop
+  ```
+  No modo `conflito`, a mensagem usa os nomes reais (`Merge branch '<origem>' into <destino>`) e o push vai para o branch atual.
+- Decisão semântica que abriu precedente (ex.: como tratar migration fora de ordem, padrão de conflito recorrente) → proponha gravar um `DEC` no RAG. Com o ok do usuário, `gravar_conhecimento` com `origem='AUT'`, `autor` = `git config user.name`, `hostname_usuario` = `$env:COMPUTERNAME`, `modelo_llm` = id do modelo da sessão. Falha na gravação → mostre o conteúdo no chat para regravar com `/altis-rag`.

package/payload/rules/altis-rag-rule.md

@@ -26,7 +26,8 @@ Gravação manual explícita: comando `/altis-rag`.
   `banco-oracle`, `banco-postgres`, `repositorio`, `nfe`, `sitef`, `integracoes`, `python`.
 - `autor`: `git config user.name` · `hostname_usuario`: `$env:COMPUTERNAME` · `modelo_llm`: model
   id da sessão.
-- `origem`: `MAN` fora dos orquestradores, `AUT` dentro de `/altis-feature` e `/altis-bugfix`.
+- `origem`: `MAN` fora dos orquestradores, `AUT` dentro de `/altis-feature`, `/altis-bugfix` e
+  `/altis-git-merge`.
 - Resposta com `gravado=false` + `similares`: atualize o existente (`atualizar_conhecimento`) ou
   regrave com `forcar=true` se for mesmo distinto.
 

package/payload/skills/git_esp/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: git_esp
+description: Base do altis-git-agent (disparado pelo /altis-git-merge) — merge master → develop sem commit, inventário e classificação de conflitos (mecânico × semântico), encoding Delphi na resolução, checagem estática e relatório. Fora desse agente, para fazer ou resolver merge, use o /altis-git-merge.
+---
+
+# Merge e conflitos git na Altis
+
+O monorepo (`E:/Projetos/1develop`, remoto `origin` = `github.com/altissistemas/altis`) tem dois branches longos: `master` é a versão em produção (7.0.x) e `develop` a próxima (7.1.x). Tickets saem dos dois (`ticket_<N>_master_7.0`, `ticket_<N>_develop_v7.1`). Hotfix da master chega ao develop por "Merge branch 'master' into develop".
+
+O shell não guarda estado entre chamadas da tool Bash: comece cada comando com `cd "<raiz do repositório>"`. Use `git -c core.quotepath=false` nos comandos que listam caminhos — o monorepo tem `Orientado a Objetos/`, `Scripts de banco/` e nomes com acento.
+
+## Limites git
+
+Esta tabela vale **só para o `altis-git-agent`**, dentro da exceção da regra 1 do `CLAUDE.md` do monorepo. Qualquer outra sessão ou agente que leia esta skill fica nas linhas de leitura e encaminha o merge ao `/altis-git-merge`.
+
+| Pode | Quando |
+|---|---|
+| `status`, `log`, `diff`, `show`, `blame`, `merge-base`, `ls-files`, `ls-tree`, `cat-file`, `rev-parse`, `rev-list`, `symbolic-ref`, `for-each-ref`, `remote` | sempre (leitura) |
+| `git fetch origin` | modo `merge` |
+| `git switch develop` e `git merge --ff-only origin/develop` | modo `merge`, só com a árvore limpa |
+| `git merge --no-ff --no-commit origin/master` | modo `merge` |
+| `git checkout --ours -- <arq>` / `git checkout --theirs -- <arq>` | resolver o arquivo inteiro por um lado |
+| `git rm -- <arq>` | resolver apagado × alterado quando a escolha foi apagar |
+| `git add -- <arq>` | arquivo do merge (conflito resolvido, ou corrigido na verificação), depois da checagem estática |
+
+Nada além disso escreve no repositório. **Nunca:** `commit`, `push`, `merge --abort`, `reset`, `rebase`, `stash`, `clean`, `restore`, `worktree`, `branch -D`, `tag`, nem `checkout` sem `--ours`/`--theirs`. Abortar descarta todas as resoluções: quando for o caminho, o relatório diz que o usuário roda `git merge --abort`.
+
+`--ours` e `--theirs` durante um merge:
+
+| | `--ours` / `HEAD` / stage `:2:` | `--theirs` / `MERGE_HEAD` / stage `:3:` |
+|---|---|---|
+| merge master → develop | develop | master (`origin/master`) |
+| merge do develop dentro de um ticket | o ticket | develop |
+
+## Ler o estado
+
+```bash
+cd "<raiz>"
+git symbolic-ref --short -q HEAD || echo "HEAD destacado"
+git rev-parse -q --verify MERGE_HEAD && head -1 "$(git rev-parse --git-path MERGE_MSG)"
+test -d "$(git rev-parse --git-path rebase-merge)" -o -d "$(git rev-parse --git-path rebase-apply)" && echo "REBASE EM ANDAMENTO"
+git rev-parse -q --verify CHERRY_PICK_HEAD >/dev/null && echo "CHERRY-PICK EM ANDAMENTO"
+git -c core.quotepath=false status --porcelain=v1
+```
+
+- Rebase ou cherry-pick em andamento: fora do escopo. Reporte e pare.
+- Sem `MERGE_HEAD` nos modos `master-develop` e `conflito`: não há merge para resolver. Reporte e pare, sugerindo o modo `merge` se o pedido era trazer a master.
+- Modo `master-develop`: `HEAD` precisa ser `develop` e `MERGE_HEAD` precisa ser a ponta de `master` ou de `origin/master` (`git rev-parse master origin/master MERGE_HEAD`). Se não for, **não toque em nada**: devolva como pergunta, sugerindo o modo `conflito`.
+- Modo `conflito`: os nomes dos dois lados são o branch atual e o que aparece na primeira linha do `MERGE_MSG`.
+
+Variáveis de shell não sobrevivem entre chamadas: um `$MB` vazio vira `..HEAD`, devolve nada e esconde o histórico sem erro. Use as formas sem estado — `MERGE_HEAD..HEAD` (o que HEAD fez desde o merge-base), `HEAD..MERGE_HEAD` (o que a origem fez), `HEAD...MERGE_HEAD` no `git diff` (do merge-base até a origem) e `:1:<arq>` (o arquivo no merge-base).
+
+## Pré-checagens do modo `merge`
+
+Na ordem. **Para** encerra a rodada com `Perguntas pendentes`, sem tocar em nada:
+
+1. Existem o remoto `origin` e os branches `master` e `develop` (`git remote`, `git rev-parse --verify`) — senão **para**.
+2. Nenhum merge, rebase ou cherry-pick em andamento — senão **para** (se for merge, sugira `master-develop` ou `conflito`).
+3. Árvore limpa: `git status --porcelain=v1 --untracked-files=no` vazio — senão **para**, listando os arquivos. Você não faz stash: o usuário commita ou guarda as mudanças dele.
+4. `git fetch origin`.
+5. Develop local × `origin/develop`: `git rev-list --left-right --count develop...origin/develop`.
+   - `0 0` em dia; `0 N` atrás (atualize depois do switch);
+   - `N 0` à frente: **avise** que os commits locais não enviados entram no merge, e siga;
+   - `N M` divergente: **para**.
+6. Master local à frente de `origin/master` (`git rev-list --count origin/master..master` > 0): **avise** que esses commits não entram (o merge usa `origin/master`) e siga.
+7. Nada a trazer (`git rev-list --count develop..origin/master` = 0): reporte "o develop já contém a master" e pare, sem pergunta.
+8. `git switch develop` (se não estiver nele) e, se estava atrás, `git merge --ff-only origin/develop`.
+9. `git merge --no-ff --no-commit origin/master`. Saída com `CONFLICT` é o esperado. Recusa porque um arquivo não rastreado seria sobrescrito → **para**, listando os arquivos.
+
+Registre quantos commits vieram (`git rev-list --count HEAD..MERGE_HEAD`) e `git log --oneline HEAD..MERGE_HEAD`.
+
+## Inventário
+
+```bash
+git -c core.quotepath=false diff --name-only --diff-filter=U
+git -c core.quotepath=false status --porcelain=v1 | grep -E '^(UU|AA|DU|UD|AU|UA|DD) '
+```
+
+| Código | Significado | Ponto de partida |
+|---|---|---|
+| `UU` | os dois lados alteraram | blocos `<<<<<<<` / `=======` / `>>>>>>>` no arquivo |
+| `AA` | os dois lados criaram o mesmo caminho | idem; idênticos depois de normalizar o fim de linha → mecânico |
+| `DU` / `UD` | um lado apagou, o outro alterou | sempre semântico |
+| `AU` / `UA` / `DD` | só um lado adicionou / os dois apagaram | raros; trate como semântico |
+
+Cada lado fica acessível: `git show :1:<arq>` (merge-base), `:2:` (ours), `:3:` (theirs). Depois do `git add`, use `HEAD:<arq>` e `MERGE_HEAD:<arq>`.
+
+Liste também o que a origem trouxe, por camada (o orquestrador usa na verificação): `git -c core.quotepath=false diff --name-only HEAD...MERGE_HEAD`.
+
+## Classificação
+
+Leia `~/.claude/skills/git_esp/references/conflitos-por-tipo.md` antes da primeira resolução; nos modos `merge` e `master-develop`, leia também `~/.claude/skills/git_esp/references/master-develop.md`. Resumo:
+
+**Mecânico** — você resolve sozinho:
+- os dois lados acrescentaram itens independentes numa lista: units (`uses`, `.dpr`), `DCCReference` (`.dproj`), imports, sequences, casos de teste;
+- `Comandos adicionar na update.sql` quando os dois lados **só acrescentaram** comandos ao fim;
+- linhas vizinhas que não se sobrepõem logicamente;
+- diferença só de formatação, espaço ou fim de linha;
+- versão do `.dproj` e `.res` de versão no sentido master → develop (fica a do develop).
+
+**Semântico** — vai ao usuário:
+- a mesma lógica (método, procedure, trigger, regra, query) alterada pelos dois lados;
+- `DU`/`UD`, `AA` com conteúdo diferente, renomeado × renomeado;
+- `.dfm` com o mesmo componente alterado pelos dois lados em propriedade que não é de layout;
+- binário que não seja recurso de versão;
+- qualquer caso em que você não tenha certeza.
+
+Arquivo com um bloco mecânico e outro semântico: resolva o mecânico e deixe o arquivo **sem** `git add` até a rodada 2.
+
+## Conflito semântico: opções e recomendação
+
+Levante o porquê de cada lado antes de opinar:
+
+```bash
+git log --oneline MERGE_HEAD..HEAD -- "<arq>"
+git log --oneline HEAD..MERGE_HEAD -- "<arq>"
+git show <commit> -- "<arq>"
+```
+
+O ticket costuma estar no nome do branch mesclado (`git log --merges --oneline HEAD..MERGE_HEAD`) ou na mensagem do commit.
+
+Opções (no modo `conflito`, com os nomes reais dos branches no lugar de develop/master):
+- **Combinar** — o texto final exato, que será aplicado como está se o usuário escolher;
+- **Manter develop** — dizendo o que da master se perde (ex.: "perde o fix do ticket 11780");
+- **Manter master** — dizendo o que do develop se perde.
+
+Recomende a opção que preserva a intenção dos dois lados com menos risco, em uma ou duas frases. Padrões frequentes:
+- master corrigiu um bug e develop refatorou o mesmo trecho → **Combinar**, aplicando a correção sobre a versão refatorada;
+- develop já tem a mesma correção por outro caminho (confira no `git log`/`git show`) → **Manter develop**, citando o commit que cobre;
+- um lado apagou e o outro corrigiu → sem o motivo da remoção não há recomendação segura: diga isso e recomende a opção que preserva o comportamento de produção.
+
+Um hotfix da master nunca some em silêncio.
+
+## Combinar código de uma stack
+
+A versão combinada segue os padrões da stack (nomes, mensagens PT-BR, filtro de empresa). Leia a skill pelo caminho:
+
+| Arquivo | Skill |
+|---|---|
+| `.pas`, `.dpr`, `.dfm` | `~/.claude/skills/delphi_esp/SKILL.md` |
+| `.sql` em `Scripts de banco/` | `~/.claude/skills/oracle_esp/SKILL.md` |
+| `.sql` em `ScriptsPostgreSQL/` ou `db/migration/` | `~/.claude/skills/postgreSQL_esp/SKILL.md` |
+| `.java` | `~/.claude/skills/java_spring_skill/SKILL.md` |
+| AltisW (`.ts`, `.html`, `.css`) | `~/.claude/skills/angular_esp/SKILL.md` |
+| `ReactNative/AltisMobile` | `~/.claude/skills/reactnative_esp/SKILL.md` |
+| `.py` | `~/.claude/skills/python_esp/SKILL.md` |
+| `.go` | `~/.claude/skills/go_lang_esp/SKILL.md` |
+
+## Editar: encoding primeiro
+
+Antes da primeira edição num arquivo de texto com acento (`.pas`, `.dpr`, `.dfm`, `.sql`…), classifique **cada lado** com o script de `~/.claude/skills/git_esp/references/encoding.md` (protocolo da regra `delphi_encoding_rule`). Classificar só o arquivo de trabalho não basta: com um lado em UTF-8 e o outro em Windows-1252 ele parece Windows-1252 com BOM.
+
+| `ours` × `theirs` | Como editar |
+|---|---|
+| os dois UTF-8 (com ou sem BOM) ou um deles ASCII | `Edit`: `old_string` = o bloco inteiro, do `<<<<<<<` ao `>>>>>>>`; `new_string` = a resolução |
+| os dois Windows-1252 (ou um deles ASCII) | só em bytes, com o resolvedor de `encoding.md`: bloco escolhido por âncora, resolução montada com os bytes dos lados sempre que der — sem redigitar acento |
+| um UTF-8 com acento e o outro Windows-1252 | semântico: um branch converteu o encoding — pergunte |
+| algum lado com `U+FFFD` | pendência: o arquivo já veio corrompido |
+
+Para ler um arquivo Windows-1252 use o visualizador de `encoding.md` (`PYTHONIOENCODING=utf-8`): o `Read` mostra `�` no lugar dos acentos.
+
+O `delphi_guard` só vê o `Edit`. Numa edição em bytes de `.pas`, aplique você a mesma regra: texto resolvido com `ShowMessage`, `MessageDlg` ou `MessageBox` não é gravado — vira pendência, como se o guard tivesse negado. Quando o guard negar um `Edit`, não reescreva o trecho para escapar dele nem repita a edição por Bash: pendência.
+
+Arquivo inteiro de um lado (binário, `DU`/`UD` decidido, `AA` idêntico): `git checkout --ours|--theirs -- <arq>`; apagar: `git rm -- <arq>`.
+
+## Checagem estática
+
+Por arquivo, antes do `git add`:
+
+```bash
+grep -nE '^(<<<<<<<|\|\|\|\|\|\|\||=======|>>>>>>>)( |$)' "<arq>"   # nenhuma linha
+```
+
+| Tipo | Checagem extra |
+|---|---|
+| `.pas`, `.dpr`, `.dfm` | `U+FFFD` = 0; todo `\n` precedido de `\r`; encoding igual ao de antes da edição |
+| `.dpr` | toda unit de `in '<caminho>'` existe em disco e nenhuma se repete (script em `conflitos-por-tipo.md`) |
+| `.dproj`, `.xml` | XML bem-formado: `python -c "import sys, xml.dom.minidom; xml.dom.minidom.parse(sys.argv[1])" "<arq>"` |
+| `.json` | `node -e "JSON.parse(require('fs').readFileSync(process.argv[1],'utf8'))" "<arq>"` |
+| `.sql` | `U+FFFD` = 0 |
+
+Passou → `git add -- "<arq>"`. Não passou → sem `git add`; o arquivo vai para **Pendências** com o motivo.
+
+## Rodadas
+
+- **Rodada 1:** pré-checagens (modo `merge`) → estado → inventário → mecânicos resolvidos, checados e staged → semânticos com opções → alertas → relatório.
+- **Rodada 2:** o briefing traz a escolha de cada bloco ou uma instrução livre do usuário. Aplique exatamente o texto de "Combinar" proposto na rodada 1 (que vem no briefing) ou o que o usuário pediu; checagem; `git add`.
+- **Rodada 2 por BLOQUEADOR do code review:** o arquivo já está staged e sem marcadores. Edite o texto resolvido conforme o achado (mesmo protocolo de encoding), refaça a checagem e o `git add`. Se o achado pede recomeçar a resolução do zero, isso é pergunta pendente: o usuário recria o conflito com `git checkout -m -- <arq>` (fora dos seus limites) e o orquestrador te dispara de novo.
+- **Fechamento:** confirme `git diff --name-only --diff-filter=U` vazio e nenhum marcador nos arquivos staged (`git diff --cached --name-only` + o `grep` da checagem); faça a checagem e o `git add` dos arquivos que os agentes de stack corrigiram na verificação (lista no briefing); devolva `git status --short` e a primeira linha do `MERGE_MSG`.
+
+## Relatório
+
+Seção vazia: escreva "nenhum".
+
+```
+## Estado
+modo: <merge|master-develop|conflito> · rodada: <1|2|fechamento>
+branch: <HEAD> ← <origem do merge> · MERGE_HEAD: <sha curto> · merge-base: <sha curto>
+commits trazidos: <n> — `git log --oneline HEAD..MERGE_HEAD` (até 20)
+
+## Pré-checagens (modo merge)
+- <item>: ok | aviso | parou — <detalhe>
+
+## Arquivos trazidos pela origem, por camada
+- <Delphi | Oracle | PostgreSQL/Flyway | Spring | AltisW | AltisMobile | Python | Go | outros>: <arquivos>
+
+## Conflitos mecânicos resolvidos (staged)
+- <arq> — <como: união das units X e Y; versão do develop; ...>
+
+## Conflitos semânticos
+### <arq> — bloco <n> (linhas aprox. <a>-<b>)
+- develop: <o que mudou e por quê> (<commit/ticket>)
+- master: <o que mudou e por quê> (<commit/ticket>)
+- Combinar: <texto final exato, em bloco de código>
+- Manter develop: <o que se perde>
+- Manter master: <o que se perde>
+- Recomendado: <opção> — <por quê>
+
+## Pendências
+- <arq> — <motivo: guard negou, checagem falhou, encoding misto, ...>
+
+## Alertas
+- <migration Flyway fora de ordem, update.sql reescrito por um lado, ...>
+
+## Perguntas pendentes
+- <pergunta objetiva + opções + o que já ficou pronto>
+```

package/payload/skills/git_esp/references/conflitos-por-tipo.md

@@ -0,0 +1,96 @@
+# Resolução de conflitos por tipo de arquivo
+
+"HEAD" é o branch que recebe o merge; "origem" é o que está sendo trazido (`MERGE_HEAD`). Antes de editar, classifique o encoding (SKILL.md, "Editar: encoding primeiro"). Na dúvida entre mecânico e semântico, é semântico.
+
+## `.dpr` (`Piloto/altis.dpr`, `Piloto/Testes/altisTestes.dpr` e demais projetos)
+
+O conflito mais frequente: os dois lados acrescentaram units no fim do `uses`.
+
+- **Mecânico:** união das units — as de HEAD como estão, depois as novas da origem. Cada unit uma vez só (compare o nome sem diferenciar caixa); a última termina em `;`, as demais em `,`; preserve o comentário `{FormXxx}` de cada linha.
+- **Semântico:** conflito no bloco `begin … end.` (inicialização da aplicação), em diretivas `{$…}`, ou unit renomeada/removida por um lado.
+
+Conferência depois de resolver — toda unit existe em disco e nenhuma se repete:
+
+```bash
+python - "<caminho do .dpr>" <<'EOF'
+import os, re, sys
+fn = sys.argv[1]
+txt = open(fn, 'rb').read().decode('utf-8-sig', errors='replace')
+m = re.search(r'\buses\b(.*?);', txt, re.S | re.I)
+units = re.findall(r"([\w.]+)\s+in\s+'([^']+)'", m.group(1)) if m else []
+base = os.path.dirname(os.path.abspath(fn))
+nomes = [u.lower() for u, _ in units]
+for u, cam in units:
+    if not os.path.exists(os.path.join(base, cam.replace(chr(92), os.sep))):
+        print('FALTA NO DISCO:', u, cam)
+for n in sorted(set(nomes)):
+    if nomes.count(n) > 1:
+        print('REPETIDA:', n)
+print('units com caminho:', len(units))
+EOF
+```
+
+## `.dproj` (MSBuild XML)
+
+- **Mecânico:** `<DCCReference Include="…">` acrescentados pelos dois lados → união, sem repetir o mesmo `Include`, levando os filhos de cada item (`<Form>`, `<FormType>`).
+- **Versão** (`VerInfo_Keys` → `FileVersion`/`ProductVersion`; `VerInfo_MajorVer`, `VerInfo_MinorVer`, `VerInfo_Release`, `VerInfo_Build`):
+  - sentido master → develop: fica a do develop, em todas as configurações (`<PropertyGroup Condition=…>`) — mecânico;
+  - modo `conflito`: se um lado é igual ao merge-base (`git show :1:<arq>`), fica o que mudou; se os dois mudaram, é semântico.
+- **Semântico:** `<PropertyGroup>` de plataforma/configuração (caminhos de busca, defines, `DCC_*`) alterado pelos dois lados.
+- O resultado precisa ser XML bem-formado (checagem na SKILL.md).
+
+## `.dfm` (texto)
+
+`.dfm` binário (primeiro byte `0xFF`) → semântico, escolha de lado inteiro.
+
+- **Mecânico:** componentes diferentes acrescentados pelos dois lados (blocos `object … end` distintos) → união, cada um no seu pai; conflito só em propriedades de layout (`Left`, `Top`, `Width`, `Height`, `TabOrder`, `Explicit*`) → fica o de HEAD, listado no relatório.
+- **Semântico:** o mesmo componente com propriedade que não é de layout alterada pelos dois lados (`Caption`, eventos `On*`, `DataField`, `DataSource`, `Visible`, `Enabled`, `Hint`); componente apagado por um lado e alterado pelo outro.
+- Evento ligado no `.dfm` precisa existir no `.pas`: se a resolução traz `OnXxx = Metodo`, confira que `Metodo` está no `.pas` resolvido.
+
+## `.pas`
+
+- **Mecânico:** `uses` (união, sem repetir); declarações diferentes acrescentadas pelos dois lados na mesma seção (métodos, constantes, campos) → união, com as implementações correspondentes; linhas vizinhas sem sobreposição lógica.
+- **Semântico:** corpo do mesmo método alterado pelos dois lados; assinatura alterada por um lado e chamada nova pelo outro (procure os chamadores com `grep` antes de opinar); SQL embutido alterado pelos dois lados.
+- `delphi_guard` negou o `Edit` porque um dos lados traz `ShowMessage`/`MessageDlg`/`MessageBox`: pendência ao usuário, com o trecho. Não remova a chamada por conta própria para passar no guard (isso muda o comportamento do lado que a escreveu) nem repita a edição por Bash. Entre as opções, pode oferecer a versão com `Informar`/`Exclamar`/`Perguntar`, dizendo o que muda para o operador; ela só é aplicada se o usuário escolher.
+
+## `.sql` Oracle (`Scripts de banco/`)
+
+- **`Comandos adicionar na update.sql`:** se os dois lados só **acrescentaram** comandos ao fim (o conteúdo do merge-base continua intacto nos dois), é mecânico — união, os comandos de HEAD e depois os novos da origem, sem repetir, cada um terminado em `;` e separado do próximo por uma linha em branco. Se um lado **reescreveu ou esvaziou** o arquivo (o conteúdo do merge-base sumiu desse lado — comum depois de um release), é semântico: pergunte, mostrando os comandos que cada lado tem e o outro não.
+- **`Sequenciais.sql`:** união dos `create sequence`, sem repetir nome.
+- **Tabelas:** colunas, constraints ou índices diferentes acrescentados pelos dois lados → união, cuidando das vírgulas da lista de colunas; a mesma coluna/constraint com definição diferente → semântico.
+- **Procedures, functions, triggers, views, packages:** corpo alterado pelos dois lados → semântico.
+
+## PostgreSQL e Flyway (`ScriptsPostgreSQL/`, `SpringBoot/AltisClienteWs/src/main/resources/db/migration/`)
+
+Migration raramente conflita no texto (cada uma é um arquivo novo), mas o merge pode impedir o AltisClienteWs de subir:
+- duas migrations com a mesma versão (`V7.1.5__a.sql` e `V7.1.5__b.sql`) → o Flyway recusa versão duplicada: alerta + pergunta;
+- migration que já existia no merge-base e foi editada por um lado → muda o checksum e as bases que já a aplicaram falham na validação: alerta;
+- migration da origem com versão menor que a última de HEAD → regra de `master-develop.md`, que vale também no modo `conflito`.
+
+Cópias de documentação em `ScriptsPostgreSQL/Tabelas/` seguem a regra das tabelas Oracle.
+
+## Java e TypeScript
+
+- **Mecânico:** imports (união, sem repetir); métodos ou casos de teste diferentes acrescentados pelos dois lados → união.
+- **Semântico:** o mesmo método alterado pelos dois lados; o mesmo campo de DTO/model alterado; mapeamento de rota alterado pelos dois lados.
+
+## JSON e dependências
+
+- **`coverage-baseline.json` (AltisW):** fica o de HEAD; o `altis-angular-agent` mede de novo na verificação.
+- **`package.json` / `pom.xml`:** dependências diferentes → união; a mesma dependência com versões diferentes → semântico.
+- **`package-lock.json`:** fique com o de HEAD (`git checkout --ours -- <lock>`) e, se o `package.json` resolvido mudou dependências, regenere na pasta do projeto com `npm install --package-lock-only`. Falhou → pendência.
+- Outro JSON: conteúdo de dados → semântico; o resultado precisa parsear.
+
+## Binários e recursos
+
+- `.res` de versão do Delphi no sentido master → develop: `--ours` (develop). Nos outros casos, semântico.
+- Imagens, `.ico`, `.xlsx`, `.docx`, `.pdf` e demais binários: semântico, escolha de lado inteiro (`--ours`/`--theirs`), citando o commit de cada lado.
+
+## Apagado × alterado, renomeado
+
+- `DU`/`UD`: sempre semântico. Mostre quem apagou (`git log --diff-filter=D --oneline MERGE_HEAD..HEAD -- <arq>` para o HEAD, `HEAD..MERGE_HEAD` para a origem) e o que o outro lado mudou. Opções: manter apagado (`git rm -- <arq>`) ou manter alterado (`git checkout --ours|--theirs -- <arq>` + `git add`).
+- Renomeado × renomeado (o mesmo arquivo com nomes diferentes) e renomeado × apagado: semântico.
+
+## Espaço e fim de linha
+
+Diferença só de espaço, indentação ou CRLF/LF: fica a versão de HEAD. Arquivos Delphi terminam em CRLF.

package/payload/skills/git_esp/references/encoding.md

@@ -0,0 +1,105 @@
+# Encoding na resolução de conflitos
+
+Complementa a regra `delphi_encoding_rule`. A tool `Read` decodifica como UTF-8: num arquivo Windows-1252 os acentos aparecem como `�` e, se você salvar por `Edit`, viram `EF BF BD` no arquivo inteiro. Por isso o encoding é decidido **por lado**, antes da primeira edição.
+
+Rode os scripts a partir da raiz do repositório (`cd "<raiz>"`). Use `python`; se cair no alias da Microsoft Store, `py -3`. O `PYTHONIOENCODING=utf-8` é obrigatório: sem ele o console do Windows mostra `�` no lugar dos acentos.
+
+## 1. Classificar cada lado
+
+```bash
+PYTHONIOENCODING=utf-8 python - "<arquivo relativo à raiz>" <<'EOF'
+import subprocess, sys
+arq = sys.argv[1]
+def classe(b):
+    if b is None:
+        return 'ausente'
+    if b'\xef\xbf\xbd' in b:
+        return 'CORROMPIDO (U+FFFD)'
+    try:
+        b.decode('utf-8')
+    except UnicodeDecodeError:
+        return 'MISTO (BOM + bytes nao UTF-8)' if b[:3] == b'\xef\xbb\xbf' else 'Windows-1252'
+    if b[:3] == b'\xef\xbb\xbf':
+        return 'UTF-8 com BOM'
+    return 'ASCII' if all(x < 0x80 for x in b) else 'UTF-8 sem BOM'
+def lado(n):
+    r = subprocess.run(['git', 'show', f':{n}:{arq}'], capture_output=True)
+    return r.stdout if r.returncode == 0 else None
+for nome, n in (('base   :1', 1), ('ours   :2', 2), ('theirs :3', 3)):
+    print(nome, '->', classe(lado(n)))
+print('arquivo   ->', classe(open(arq, 'rb').read()))
+EOF
+```
+
+| `ours` × `theirs` | Como editar |
+|---|---|
+| os dois UTF-8 (com ou sem BOM) ou um deles ASCII | `Edit`: `old_string` = o bloco inteiro, do `<<<<<<<` ao `>>>>>>>` |
+| os dois Windows-1252, ou um Windows-1252 e o outro ASCII | só em bytes (seção 3) |
+| um UTF-8 com acento e o outro Windows-1252 | **semântico**: um branch converteu o encoding. Não edite; pergunte, dizendo qual lado converteu (`git log` do arquivo) |
+| algum `CORROMPIDO` | pendência: o arquivo já veio corrompido de um dos lados |
+
+O arquivo de trabalho aparece como `MISTO` quando os dois lados divergem no encoding — confirma o caso semântico.
+
+## 2. Ver os blocos de um arquivo Windows-1252
+
+```bash
+PYTHONIOENCODING=utf-8 python - "<arquivo>" <<'EOF'
+import re, sys
+data = open(sys.argv[1], 'rb').read()
+blocos = re.finditer(rb'^<<<<<<< [^\r\n]*\r?\n.*?^>>>>>>> [^\r\n]*(?:\r?\n|\Z)', data, re.S | re.M)
+for i, m in enumerate(blocos):
+    print(f'--- bloco {i}')
+    print(m.group(0).decode('cp1252'))
+EOF
+```
+
+## 3. Resolver um bloco em bytes
+
+O bloco é escolhido por uma **âncora**: um trecho que só existe nele (o índice muda a cada resolução). O modo diz como montar a resolução:
+
+| Modo | Resultado |
+|---|---|
+| `ours`, `theirs` | os bytes de um lado, como estão |
+| `ours+theirs`, `theirs+ours` | os dois lados em sequência — a união mecânica mais comum (ex.: constantes novas dos dois lados) |
+| `texto` | o texto de `novo`, gravado em Windows-1252 — para combinar trechos ou ajustar vírgulas |
+
+Prefira os quatro primeiros: eles copiam os bytes dos lados e não exigem redigitar acento.
+
+```bash
+PYTHONIOENCODING=utf-8 python - <<'EOF'
+import re
+fn = r'<arquivo>'
+ancora = '<trecho que só existe no bloco certo>'
+modo = 'ours+theirs'   # ours | theirs | ours+theirs | theirs+ours | texto
+novo = r"""<só no modo texto: o texto final, sem marcadores>"""
+enc = 'cp1252'
+data = open(fn, 'rb').read()
+eol = b'\r\n' if b'\r\n' in data else b'\n'
+padrao = re.compile(rb'^<<<<<<< [^\r\n]*\r?\n(.*?)^>>>>>>> [^\r\n]*(?:\r?\n|\Z)', re.S | re.M)
+achados = [m for m in padrao.finditer(data) if ancora.encode(enc) in m.group(0)]
+assert len(achados) == 1, f'ancora em {len(achados)} blocos: use um trecho que so exista no bloco certo'
+m = achados[0]
+partes = re.split(rb'^(?:\|{7}(?: [^\r\n]*)?|={7})\r?\n', m.group(1), flags=re.M)
+ours, theirs = partes[0], partes[-1]
+if modo == 'texto':
+    res = novo.replace('\r\n', '\n').replace('\n', eol.decode()).encode(enc)
+    if res and not res.endswith(eol):
+        res += eol
+else:
+    res = {'ours': ours, 'theirs': theirs, 'ours+theirs': ours + theirs, 'theirs+ours': theirs + ours}[modo]
+data = data[:m.start()] + res + data[m.end():]
+open(fn, 'wb').write(data)
+print('blocos restantes:', len(padrao.findall(data)))
+print(res.decode(enc))
+EOF
+```
+
+`novo` usa `r"""…"""` porque o SQL montado em Delphi tem `''` com frequência; se o texto tiver `"""`, troque o delimitador.
+
+## 4. Antes do `git add`
+
+```bash
+python -c "import sys; d=open(sys.argv[1],'rb').read(); print('FFFD', d.count(b'\xef\xbf\xbd'), '| LF sem CR', d.replace(b'\r\n', b'').count(b'\n'))" "<arquivo>"
+```
+
+`FFFD` = 0 e, em arquivo Delphi, `LF sem CR` = 0. Se você mesmo corrompeu o arquivo, não tente restaurar (`git checkout -- <arq>` está fora dos seus limites): pendência — o usuário recria o conflito com `git checkout -m -- <arq>`.

package/payload/skills/git_esp/references/master-develop.md

@@ -0,0 +1,42 @@
+# Merge master → develop
+
+Vale nos modos `merge` e `master-develop`. `HEAD`/`--ours` = **develop** (próxima versão, 7.1.x); `MERGE_HEAD`/`--theirs` = **master** (`origin/master`, produção, 7.0.x). A master traz hotfixes, quase sempre de um ticket `ticket_<N>_master_7.0` mesclado nela.
+
+## Princípios
+
+1. **O hotfix chega ao develop.** O motivo do merge é levar correções de produção à próxima versão. Toda opção que descarta código da master diz qual correção se perde.
+2. **A versão é do develop.** `FileVersion`/`ProductVersion` do `.dproj`, `VerInfo_*` e o `.res` de versão ficam com os valores do develop — mecânico.
+3. **Listas se unem.** Units do `.dpr` (`altis.dpr`, `Testes/altisTestes.dpr`), `DCCReference` do `.dproj`, sequences e casos de teste: união.
+4. **Refatoração no develop + correção na master, no mesmo trecho,** é o semântico mais comum: recomende **Combinar**, aplicando a correção sobre o código refatorado, e mostre o texto final.
+5. **Develop já corrigiu do jeito dele:** confira em `git log --oneline MERGE_HEAD..HEAD -- <arq>`. Se a correção da master já está coberta, recomende **Manter develop** citando o commit que cobre.
+
+## Migration Flyway fora de ordem
+
+O `PostgreSqlFlywayMigrator` do AltisClienteWs (Flyway 10, via Spring Boot 3.3.5) não configura `outOfOrder` e mantém o `validateOnMigrate` padrão. Uma migration da master com versão **menor** que a última do develop (ex.: `V7.0.10` chegando num develop que já tem `V7.1.9`) fica `IGNORED` nas bases que já aplicaram a `V7.1.9`; a validação falha e o migrator lança `IllegalStateException` — o AltisClienteWs não sobe.
+
+Detecte em toda rodada 1:
+
+```bash
+D='Orientado a Objetos/SpringBoot/AltisClienteWs/src/main/resources/db/migration'
+git -c core.quotepath=false diff --name-only --diff-filter=A HEAD...MERGE_HEAD -- "$D"
+git -c core.quotepath=false ls-tree -r --name-only HEAD -- "$D"
+```
+
+Compare as versões numericamente, componente a componente (`7.0.10` < `7.1.9`; `7.1.10` > `7.1.9`). Para cada migration da master menor que a maior do develop:
+- **alerta** em destaque no relatório;
+- **pergunta pendente** com as opções e a consequência de cada uma — você não renomeia nada sozinho:
+  - **levar a quem mantém o AltisClienteWs** para habilitar `outOfOrder` no `PostgreSqlFlywayMigrator` (recomendado): a `V7.0.10` passa a ser aplicada fora de ordem nas bases do develop, e as bases 7.0 que já a rodaram seguem válidas. É mudança de código Java, fora deste merge;
+  - renomear para a próxima versão livre do develop (ex.: `V7.1.10__<descricao>.sql`): as bases do develop aplicam, mas as bases 7.0 que já rodaram a `V7.0.10` quebram ao atualizar para a 7.1 — a migration aplicada some do código e a validação acusa "applied migration not resolved locally" (exige `flyway repair` ou `ignoreMigrationPatterns` com `*:missing`), e o SQL roda de novo (só seguro se for idempotente);
+  - manter e registrar como pendência: o AltisClienteWs não sobe nas bases do develop que já aplicaram a versão maior.
+
+Renomear não está nos limites git: se o usuário escolher, quem roda é ele, antes do commit. Deixe o comando pronto na pergunta e no relatório: `git mv "<caminho>/V7.0.10__x.sql" "<caminho>/V7.1.10__x.sql"`.
+
+## Comandos de update
+
+O `Comandos adicionar na update.sql` costuma ser reescrito a cada release, e master e develop podem ter conteúdos bem diferentes. Siga a regra de `conflitos-por-tipo.md`: só é mecânico quando os dois lados apenas acrescentaram ao fim; caso contrário, pergunte.
+
+Os comandos que vêm da master já podem ter rodado nas bases 7.0 (o hotfix foi para produção). Na união, liste-os em **Alertas**: um `alter table … add` repetido no update da 7.1 dá `ORA-01430` se o processo de update não tolerar reexecução — o usuário confere.
+
+## Onde costuma conflitar
+
+Nos merges master → develop de 2026: `Piloto/altis.dpr` e `Piloto/altis.dproj` (em todos), `Piloto/Testes/altisTestes.dpr`, units de `Piloto/Banco/`, `Piloto/MenuPrincipal.pas`, scripts de `Scripts de banco/Tabelas/` e `Triggers/`, Java do AltisClienteWs, specs do AltisW e `coverage-baseline.json`.