port-from-golisted

# Port from Go ## A construct mapping and a boundary, nothing else This skill maps Go semantics and owns the Go boundary; process is `/port-to-rust`. Go syntax maps almost mechanically and the runtime model does not, so the easy-looking translation is where the port goes wrong. ## The end state, and why Go usually lands on A `/port-to-rust` names three end states; Go ports land on A — no bindings — far more often than Python or JavaScript ports do, because the cost of the alternative is cgo and a Go system almost always already has a boundary to strangle at. A default, not a rule: B is real when the deliverable is a Go-importable package; C when a leaf function moves before its callers. ## The seam is usually a process, not a function call Go has no cheap in-process FFI: cgo works in both directions but is slow at the call, awkward in the build, and drags the Go runtime along. For most Go ports the right seam is one the system already has — an HTTP route, a gRPC service, a subcommand, a queue consumer — and the strangler strategy in `/port-to-rust` is the default, not in-place FFI; mechanics and the cgo escape hatch are in `BOUNDARY.md`. ## The traps that break parity silently | Trap | What actually differs | |---|---| | Integer overflow | Go wraps on overflow, always. Rust panics in debug and wraps in release. Any arithmetic that could overflow needs an explicit choice — `wrapping_add` to reproduce Go, or checked arithmetic plus a decision about what the new error pa