3 Finding and Integrating Missing Capabilities🔗ℹ

Rivet applications are not limited to modules implemented inside this repository. Start with Racket’s standard libraries and Package Catalog, then choose the narrowest maintainable integration boundary:

• Use a maintained Racket package for portable application logic. Inspect installed packages with raco pkg show, package metadata with raco pkg catalog-show --modules and local documentation with raco docs.

• Keep UI, lifecycle, accessibility, device, and operating-system services in the WinUI, SwiftUI/AppKit, or GTK native host.

• Use ffi/unsafe behind a small checked Racket module when a stable C ABI requires frequent in-process calls. Explicitly own pointers, callbacks, threads, ABI checks, and native-library packaging.

• Use subprocess or system* for coarse-grained tools. Pass an executable and argument vector instead of constructing a shell command; add timeouts, bounded and concurrently drained output, cancellation, exit checks, version probes, packaging, and license verification.

• Reserve a sidecar for persistent or streaming runtimes, unstable ABIs, or required crash isolation. Own authentication, version negotiation, resource limits, lifecycle, recovery, distribution, and offline behavior.

Generated projects repeat this decision order in "AGENTS.md", and raco rivet inspect --json exposes it as structured capability-sourcing data. Every external capability must also pass license, Racket CS, platform/architecture, deterministic installation, failure-path, packaged dependency-closure, and clean-machine checks.