rust-port

The goal is the Rust a Rust developer would have written to solve the same problem, with the same observable behavior. A line-by-line transliteration, C written in Rust syntax or Python with Box<dyn Any>, compiles but keeps every problem the original had and adds the borrow checker on top. Port the behavior, not the structure. First, understand the original before writing anything: read the code and its tests and anything that calls it; list the observable behavior, every public function, its inputs, its outputs and every way it can fail, including the quiet parts, ordering of results, tie breaking, empty input, whitespace and case handling, integer limits, and what counts as an error versus a valid edge case; note what is incidental, things the original only does because of its language, such as manual memory management, out-parameters, NULL returns, global state, fixed-size buffers, a class that exists only to group functions, or isinstance checks; and if the original has a bug or an ambiguity, keep its behavior, flag it in the porting notes, and let the user decide, since a port is not the place to silently fix things. Second, port the tests first. Translate the original tests into Rust tests before porting the implementation, keeping one Rust test per original test, with a name that maps back to it, so a reader can check coverage. The tests are the definition of "same behavior". If the original has no tests, write characterization tests from the behavior list. Third, design the Rust API from the behavior list, not from the original's shape, then implement against the ported tests, using the mapping tables for C and C++, Python, and Go, JavaScript and TypeScript in the skill. Keep the port proportionate: match it on the inputs it actually receives, use Rust's standard library for the rest, do not reimplement the source language's runtime, do not grow the API beyond the original's public surface plus the standard trait impls Rust callers expect, and keep the algorithm unless it is wrong, saying so in the notes when it is swapped. As a size check, a port from C or C++ usually lands near the original's size, while a port from Python or JavaScript usually lands at two to three times the original, because types, error enums and their trait impls are explicit in Rust. Limits as written in the SKILL.md: verify with cargo build, cargo test and cargo clippy with warnings denied if a Rust toolchain is available, and fix everything before reporting. Every ported test must pass, and if the original's tests can be run too, run them and compare results on the same inputs. Alongside the code, write a short PORTING.md with an API mapping table, a test mapping, deliberate differences, preserved quirks, and verification, meaning which commands were run and their result, or a plain statement that they could not be run. Differential testing against the original is worth doing, but a few dozen realistic and edge-case inputs answer the question, while a fuzzing harness over millions of inputs usually just finds exotic divergences that belong in the notes.