{
  "version": "act 2.0.0",
  "slug": "port-verify",
  "name": "port-verify",
  "description": "Gate a cross-language port for correctness \u2014 composes port-scoped behavioral equivalence, contract parity, and port-manifest drift into a port-correctness verdict. Use to verify that a ported function matches its source before marking the port done.",
  "url": "https://act101.ai/docs/skills/port-verify",
  "body_md": "# port-verify\n\nA **port-correctness gate**: confirm a ported function behaves like its source\nand that the port manifest is not drifting. Composes two Enterprise verification\nops with the port inventory.\n\n## Honesty caveat (read first)\n\nThis is a structural/contract comparison (v1), not execution-based differential\ntesting. `verify_port_parity` and `verify_behavioral_equivalence` (scope=port)\ncompare only dimensions BOTH grammars model \u2014 a dimension modeled by one side\nonly is reported `unknown`, never falsely `preserved`/`diverged`. Each result\ncarries `modeled_kinds`; an empty set for either grammar means that dimension is\nuncovered. Per-grammar degradation across the source/target language pair is the\nnorm \u2014 name both languages and the uncovered dimensions. Verdicts are advisory.\n\n## Tier\n\n**Enterprise.** `verify_behavioral_equivalence` at `scope:\"port\"`,\n`verify_port_parity`, and the `port_*` manifest/inventory tools are all\nEnterprise and enforce the tier themselves.\n\n## Tools (in order)\n\n| Step | Tool | What it answers |\n|---|---|---|\n| 1 | `verify_behavioral_equivalence` (`scope:\"port\"`) | Do the source and ported functions have an equivalent control-flow shape under cross-language normalization? |\n| 2 | `verify_port_parity` | Do signature arity, return presence, effect-kind set, CFG shape, and raise count match across the language pair? |\n| 3 | `port_inventory` | Is the manifest consistent \u2014 is this symbol marked ported, and is the target verified? Surfaces drift. |\n\n## Workflow\n\n1. Call `verify_behavioral_equivalence` with `scope:\"port\"`, the source\n   `target`/`file` and the ported version (via `before`/`after` or the manifest\n   mapping). `equivalent` confirms shape held; `changed` lists which dimensions\n   diverged; `unknown` means a dimension could not be normalized across the pair\n   \u2014 do not claim parity on it.\n2. Call `verify_port_parity` with `source_file`/`source_target` and\n   `ported_file`/`ported_target`. Read the verdict (`preserved`/`diverged`/\n   `unknown`), the `dimensions_checked`, and every `mismatch`. A `diverged`\n   dimension is a hard gate failure.\n3. Call `port_inventory` to check manifest state for the file: is it marked\n   ported, are ported/stubbed symbols recorded, does target verification pass?\n   A symbol that is structurally equivalent but absent/stubbed in the manifest\n   is **drift** \u2014 the manifest and reality disagree.\n\n## Verdict synthesis\n\n- **PORT VERIFIED** \u2014 `equivalent` (port scope) AND parity `preserved` with\n  \u22651 jointly-modeled dimension AND the manifest marks the symbol ported with a\n  verified target.\n- **PORT DIVERGED** \u2014 equivalence `changed` or parity `diverged` on any modeled\n  dimension; report the exact dimension and the mismatch.\n- **MANIFEST DRIFT** \u2014 structurally equivalent but the manifest disagrees\n  (unrecorded, stubbed, or unverified target).\n- **UNKNOWN** \u2014 either op returned `unknown`/empty `modeled_kinds` on a\n  dimension; name the source+target languages and the uncovered dimension.\n  Never present UNKNOWN as VERIFIED.\n\n## Output\n\nPer ported symbol: the equivalence result, the parity verdict with\ndimensions_checked + mismatches, the manifest status, and the gate verdict.\nQuote `modeled_kinds` for both languages on any UNKNOWN."
}