Porting — Cross-Language Code Migration for AI Agents
Agent port C to Rust. Agent port Ruby to Elixir. Agent port COBOL to Java. Agent port Python 2 to Python 3. The 8 porting operations below let an AI agent execute a full source-to-target language migration through a contract / inventory / ordering / manifest state machine — between any two of act's 163 supported grammars.
Methodology
Porting a codebase with act101 follows a structured, incremental process designed to make the migration auditable and reversible at every step. The workflow separates understanding from execution: you build a complete picture of what needs to move before a single line changes.
- Define the contract. Call
port_contractto specify the source language, target language, and scope. This anchors all subsequent operations to a single manifest. - Inventory the work. Call
port_inventoryto enumerate every symbol, module, and dependency that must be ported. The inventory captures what exists, not what you intend to do — ground truth before any decisions are made. - Establish ordering. Call
port_orderto resolve dependencies between inventory items and produce a topological execution sequence. Porting in dependency order prevents referencing symbols that don't exist yet in the target. - Maintain the manifest. Use
port_manifest_init,port_manifest_add,port_manifest_update,port_manifest_remove, andport_manifest_noteto track progress, annotate decisions, and keep the port state machine current as work proceeds.
Each operation is idempotent and can be re-run as the source codebase evolves. The manifest is the single source of truth — commit it alongside your code so collaborators and CI can observe port status without re-running analysis.
Operations
| Operation | Description | Parameters |
|---|---|---|
port_contract | Extract behavioral contracts (signatures, error paths, guard clauses, side effects, purity, complexity) from a source file. Use before porting to understand what the target must replicate. Params: file (string) [, symbol (string)] | file (string) [, symbol (string)] |
port_inventory | Compute porting inventory from the manifest — overall progress, available symbols (ported/stubbed), per-file status, and target verification. Params: none [, status (string)] | none [, status (string)] |
port_manifest_add | Add a file mapping to the port manifest. Tracks which source file maps to which target file. Params: source (string) [, target (string), status (string), notes (string)] | source (string) [, target (string), status (string), notes (string)] |
port_manifest_init | Initialize a new port manifest. Creates .act/port-manifest.json to track a cross-language porting project. Params: source_root (string), source_lang (string), target_root (string), target_lang (string) | source_root (string), source_lang (string), target_root (string), target_lang (string) |
port_manifest_note | Set a top-level note on the port manifest — use for project-wide context, decisions, or conventions. Params: text (string) | text (string) |
port_manifest_remove | Remove a file mapping from the port manifest. Params: source (string) | source (string) |
port_manifest_update | Update a mapping in the port manifest — change status or record ported/stubbed/skipped symbols. Params: source (string) [, status (string), ported (string[]), stubbed (string[]), skipped (string[]), notes (string)] | source (string) [, status (string), ported (string[]), stubbed (string[]), skipped (string[]), notes (string)] |
port_order | Compute the optimal porting order — ranks remaining files by dependency depth, blocking count, and readiness. Use to decide what to port next. Params: none [, top (u32)] | none [, top (u32)] |