is ectomigo vulnerable to false positives or false negatives?

Data access code is immensely complicated, and SQL in particular is often constructed piece-by-piece and intermixed into other programming languages. Once conditional logic enters the picture, the only sure way to extract parseable SQL is to run the program -- well beyond the scope of a static analyzer. So ectomigo will never catch every single thing; the goal is to catch enough to cut down the overall risk posed by schema changes.

False positives are less likely than false negatives, but can still happen. "Select a value from the dropdown" is perfectly valid SQL, even though humans can tell it's probably user instructions instead!

All this is why ectomigo is a first line of defense against migration risk. It may be incapable of forgetting where it's seen data access code, but it can't evaluate relevance as well as a human can. Even so, early builds have already prevented several production outages for testers.

why agpl? do i have to do anything to comply?

The short answer is "you don't have to do anything, or worry about license pollution": ectomigo is a standalone system that doesn't integrate with your code. Its license, just like that of Linux (GPL) or MongoDB (AGPL), has no bearing on your ability to maintain your own proprietary code or services which happen to interact with ectomigo.

What the AGPL does do is ensure that anything based directly on public ectomigo code must itself be released under the same terms. Merely using ectomigo in your builds doesn't qualify.

when will ectomigo support xyz platform/language/framework/tool?

There's no roadmap yet, but let us know if there's something you want to see!