act101 proves your ported code behaves like the original — by extracting contracts, generating inputs, and running both versions in a sandbox to diff outputs. The verification artifact a steering committee accepts.
That's verify_port_parity. No diff tool, no LSP, no manual review produces that artifact.
Language migrations don't fail at the syntax layer. They fail at five predictable junctures — picking the wrong file to port first, porting in the wrong dependency order, silently losing behavior the source handled, losing track of what's done and why, and failing to answer "how much is left." Enterprise is built for those five points.
Most migrations stall on the first decision: which module to port first. Pick wrong — high coupling, deep dependencies, untyped boundaries — and you're rewriting your rewrite in week three.
act assesses the whole codebase before the first port: readiness scores per file, natural service boundaries, API surface width, type-completeness gaps, orphan types, dead code, and coupling hotspots. The team starts with the files that are actually safe to start with.
Port a module before its dependencies and the result is a stub. Port them out of order across a five-hundred-file codebase and every leaf gets re-touched.
act recommends the next file from the un-ported set, leaves-first and dependency-aware. Ports land in the order the build actually wants — not the order of whoever opened the file.
The new code compiles. The tests pass. Six months in, production reveals the rewrite quietly dropped a guard clause, an error path, or a resource cleanup the source did correctly.
act extracts the source file's behavioral contract before the port — guard clauses, error paths, resource patterns, complexity, edge-case handling. The target has to satisfy that contract. Drift surfaces in review, not in production.
Six months in, no one on the team can tell you what's ported, what's stubbed, what's skipped, or why a decision was made the way it was. The migration becomes archaeology.
act keeps a persistent record of the migration: per-file status, symbol-level progress, and the notes that explain every decision while the context is still fresh. New contributors pick up where the last one stopped.
"Are we thirty percent done or seventy?" No one can answer it without re-scanning the source. Project plans drift; engineering trust erodes.
act answers the percent-complete question on demand: completed files, partial files, stubbed files, and target-side drift. Status is a command away, not a rumor.
/port-verify runs continuously on the port branch. The CTO dashboard has a green/red parity number per module, every day.
generate_migration_shim and generate_adapter produce the glue so the new system runs behind the old. No big-bang cutover.
/migration-assessment combines taint, secret, unsafe, coverage, and ownership signals into a single is-this-safe-to-ship score per module.
| "How do I know this works?" | act101's answer |
|---|---|
| Tests pass on both sides. | Tests cover what someone wrote. verify_port_parity generates inputs from the contract. |
| Diff tools say the code matches. | Code matching isn't behavior matching. Different code can be equivalent. Equivalent code can drift. |
| Our LSP catches it. | LSPs cover ~5 languages. Your legacy stack probably isn't one of them. |
It starts with /migration-assessment run against your target codebase, presented to your steering committee in two weeks — the artifact they use to decide whether the program is on track.
One native binary, every grammar, zero setup. Builder Edition is free.
Download — install in 60sShip notes and new capabilities, occasionally. No spam; unsubscribe anytime.
Embedding act101 in a production agent product? → /for/fleets.