Extend rust-development with FFI and cross-language integration section

[AlexMikhalev]

Parent Epic: #62

What

Add FFI and cross-language integration patterns to rust-development SKILL.md.

Sections to Add

1. Safe C API Wrappers -- Opaque handle pattern, #[repr(C)] structs, extern "C" functions
2. Panic Catching at FFI Boundary -- std::panic::catch_unwind at every extern entry point
3. String Management Across Languages -- CString/CStr patterns, null-terminated strings, ownership transfer
4. uniffi for Automatic Bindings -- Generating Kotlin/Swift/Python bindings from Rust
5. WASM Interop Patterns -- wasm-bindgen, js-sys, shared memory, serde-wasm-bindgen

Source Reference

Section 10 (FFI and Cross-Language Integration) from RUST_SYSTEM_PROGRAMMING_BEST_PRACTICES.md

Disciplined Engineering Alignment

Phase	Skill	FFI Relevance
Research	disciplined-research	Map FFI boundary surface area; identify which language bindings needed; catalogue existing unsafe FFI
Design	disciplined-design	Define opaque handle API; specify ownership transfer rules; document WASM vs native FFI strategy
Implementation	disciplined-implementation	Each FFI function = one step with safety invariants documented; panic-catch wrappers first, then logic
Verification	disciplined-verification	Miri on unsafe FFI paths; property tests for string conversion roundtrips; fuzz parsers at boundary
Validation	disciplined-validation	Validate bindings from target language (Kotlin/Swift/JS); end-to-end cross-language integration test

The SKILL.md should note:

• During research: audit all extern blocks and unsafe FFI for safety gaps
• During design: specify ownership transfer semantics at every FFI boundary
• During verification: Miri + fuzzing mandatory for any new FFI surface

Acceptance Criteria

• SKILL.md updated with FFI section including code examples
• WASM-specific patterns included (not just C FFI)
• Unsafe code policy section cross-referenced
• Disciplined workflow integration notes included

[m13v]

Good scope. We have extensive FFI experience from Terminator (Rust desktop automation engine with Swift/Python bindings). Some additions to consider for each section:

Safe C API Wrappers: the opaque handle pattern is essential, but also document the "context object" pattern where you pass a single context pointer that bundles configuration + state. It reduces the number of FFI functions needed and makes the API easier to version.

Panic Catching: catch_unwind at every extern entry point is correct, but also mention that you need to set panic=abort in your Cargo.toml for the cdylib target if you want deterministic behavior. Unwinding across FFI boundaries is UB in Rust.

uniffi for Automatic Bindings: we use this for our Kotlin/Swift bindings in Terminator. The UDL interface definition is straightforward for simple cases. Where it gets tricky is async functions and callbacks - uniffi's async support has improved but still has rough edges with cancellation.

One section I would add: Memory Profiling Across the FFI Boundary. Leaks at the boundary are common and hard to debug because neither language's profiler sees the full picture. We use custom allocation counters on the Rust side and periodic balance checks from the calling language.

[m13v]

Our Rust FFI implementation in Terminator: https://github.com/mediar-ai/terminator/blob/main/crates/terminator/src/lib.rs

The element abstraction crossing the FFI boundary: https://github.com/mediar-ai/terminator/blob/main/crates/terminator/src/element.rs

MCP server that calls into the Rust engine: https://github.com/mediar-ai/terminator/blob/main/crates/terminator-mcp-agent/src/server.rs