port-from-clisted

# Port from C ## A construct mapping and a boundary, nothing else This skill maps C semantics and owns the C boundary; the parity contract, the five phases, and the anti-patterns are `/port-to-rust`, which runs first and stays running through the port. C++ is a separate skill — a codebase using RAII, templates, or the STL is `/port-from-cpp` even when it compiles as C. ## The end state, and why C is almost always C `/port-to-rust` names three end states; in C terms: A, a standalone Rust binary or library that replaces the C entirely; B, a Rust core with a permanent C-callable surface — the right end state when other C code links this library and will keep doing so; and C, an FFI seam that carries the migration module by module, deleted at cut-over. C codebases are rarely replaced in one step, so C is the common end state and B is common for libraries; the two are distinguished by one question — will any C code still be calling this after the port finishes? Seam mechanics: `BOUNDARY.md`. ## The traps, which are all the same trap: C did not say Each one breaks parity silently; the full table is `MAPPING.md`. | Trap | What C never recorded | |---|---| | Ownership | A `T*` may be owned, borrowed, or static. Freeing the wrong one is a double free; freeing none is a leak. The port has to decide per pointer — `Box<T>`, `&T`, or a raw pointer kept raw — and the decision usually lives in a comment or in nothing at all | | Lifetime | How long a returned pointer stays valid is co