🏚️ Safe modernization of legacy systems

AI can map dependencies, explain code, document interfaces, and find dead code — reading a lot of code and summarizing its structure is where it delivers the most value. Start there: know the actual size of the problem before proposing a solution.

Every legacy system carries rules that were never written down anywhere: historical exceptions, special cases for large customers, rounding with a tax-related reason, deadlines inherited from a 2014 contract. These are the ones that break during a rewrite.

Leia <caminho do módulo legado> inteiro. Não altere nada.

Produza uma tabela de REGRAS DE NEGÓCIO observadas no código, com colunas:
regra (em português, uma frase) | onde está (arquivo:linha) | condição que a
dispara | o que acontece quando não vale | parece intencional ou acidental?

Regras:
- descreva o que o código FAZ, não o que deveria fazer;
- inclua casos especiais, exceções, valores mágicos e datas fixas;
- não invente justificativa de negócio — se não souber, escreva "desconhecido";
- ao final, liste em "PERGUNTAR AO NEGÓCIO" as regras que parecem acidentais
  ou que você não consegue explicar.

Characterization testing records current behavior — including what seems wrong. It does not judge; it takes a snapshot. It is the safety net that makes modernization possible.

The biggest cause of post-migration incidents is simple: you turned off something “nobody used”—and someone did. A script, a spreadsheet, a report that reads the database directly, a job owned by another team.

Before changing anything, create the seam: an interface between the consumer and the implementation. With the adapter in place, you can swap the engine without touching the driver—and roll back with one line.

Both implementations receive the same input; the old one keeps responding; the new one only logs what it would respond. Every discrepancy becomes a case to investigate. This is the strongest proof there is.