Re-run acuantia through the rebuilt migrate tooling, against the hand port as ground truth

[ihistand]

The acuantia port was done by hand: eight Python codemods, ~740 rewritten sites, 53 files descoped, and roughly a dozen run-and-classify cycles. Everything learned from it has since been built into the tooling (#53, #54, #55, #56, #57, #58, plus migrate-fix and GROUP BY ALL).

The point of this run is not to migrate acuantia again — it is to measure how much of that work the tooling now does on its own. It is a rare opportunity: the hand-ported repo still exists, so there is a ground truth to diff against, which no synthetic fixture provides.

Method

Convert the ORIGINAL source, then walk the three phases:

sqlanvil migrate-dataform <acuantia-gcp-dataform> /tmp/acuantia-auto
cd /tmp/acuantia-auto && ./scripts/introspect_all.sh
sqlanvil migrate-fix .

Then diff /tmp/acuantia-auto against acuantia-sqlanvil (the hand port) and read the report.

What to measure

Coverage per class. For each construct the hand port handled, did the tool do it, and identically? The classes and their hand-port counts, as the yardstick:

class	sites	expected owner
SELECT * EXCEPT	141	migrate-fix
identifier casing	~700 refs	now moot — folded at extract
COLLATE(x, '')	66	converter
NOT ENFORCED	149	converter (commented)
GROUP BY ALL	61	migrate-fix
type names / timezones / literals	252	converter
SAFE_CAST	37	converter
backticks	93	converter
SPLIT / DAYOFWEEK / DATETIME type	21	converter
ARRAY<STRUCT>	6	report only, by design

Where the tool and the hand port disagree. The interesting output. Three kinds, and they mean different things: the tool did something the hand port did not (possibly better, possibly wrong), the hand port did something the tool missed (a gap to file), or both acted and differ (read carefully — this is where a silent semantic difference would hide).

Whether the report is actually usable as a handover. Does the class-first to-do list, the mechanical/needs-decision split and the per-site SQL let someone pick the project up? That was #56's whole claim and it has never been tested on something this size.

How much residue is genuinely a decision. The hand port needed four descope calls (dialpad, gemstone AI/BQML, the metadata views, jaro-winkler + the manufacturer chain). Those are business questions and should still appear as needs-decision — if the tool has quietly ported them instead, that is a bug in the report, not a win.

Decisions this should settle

• Whether to automate the ARRAY<STRUCT> collapse. migrate-dataform: convert ARRAY<STRUCT> rather than only flagging it #54 left it as a recommendation because it restructures the model. acuantia has the real shape — six sites, one file, feeding one flattening operation — so it is the right place to judge whether the graph evidence is strong enough to act on.
• Whether migrate-fix should also carry the remaining flag-class conversions (QUALIFY, PARSE_DATE, FARM_FINGERPRINT, json_extract_array), or whether they stay reported.
• What the residue actually looks like on a project of this size, which is the number that says whether "migrate without an agent" is realistic for anything beyond a small project.

Not in scope

Getting acuantia green. That was settled in #81: the migration is an exercise, not a deliverable. If the tooling produces a project that needs less hand-work than the original port did, this has answered its question.