mir-backend-rubylisted

Make It Right (Ruby runtime tier). YARV/MRI Ruby 3.3+ runtime reliability footguns shared across EVERY Ruby backend framework (Rails, Sinatra, Hanami, Sidekiq workers) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GVL (threads give no CPU parallelism, like Python's GIL), Puma's forked-worker + thread model, fork-safety of DB/Redis connections, copy-on-write memory and per-worker bloat, background job hygiene (Sidekiq/GoodJob idempotency, retries), and GC/frozen-string pressure. TRIGGER when the backend runtime is Ruby — sits between mir-backend (generic) and the framework module (e.g. mir-backend-ruby-rails). SKIP for Node/JVM/Go/Rust/.NET/Python/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in the framework module).
anantbhandarkar/make-it-right · ★ 12 · AI & Automation · score 83

Install: claude install-skill anantbhandarkar/make-it-right

# /mir-backend-ruby · Make It Right (Ruby runtime) The middle tier. `mir-backend` decides **what is correct** (any language). The framework module (e.g. `mir-backend-ruby-rails`) knows the **library's mechanics**. This tier owns what's true for **all Ruby backends because they run on YARV (MRI)** — the concurrency model and process model that Rails, Sinatra, Hanami, and Sidekiq all inherit. **Runtime assumed:** MRI Ruby 3.3+ running under Puma. Notes hold for JRuby except where GVL specifics differ (JRuby has no GVL; true thread parallelism is available). Load order: `mir-backend` → `mir-backend-ruby` → `<framework module>`. ## The YARV footguns AI walks into (framework-agnostic) ### 1. The GVL — threads are NOT CPU parallelism Ruby's Global VM Lock (GVL, formerly GIL) allows only one thread to execute Ruby bytecode at a time. **CPU-bound work does not run in parallel across threads** — multiple threads serialize on the GVL and you pay context-switch overhead on top. - **CPU-bound** (image processing, crypto, heavy computation): use multiple **processes** (Puma workers), a C extension that releases the GVL (`mini_magick`, `bcrypt`, `openssl` release it internally), or offload to a dedicated service / background worker. Adding more threads will not help — it will make things worse. - **I/O-bound** (DB queries, HTTP calls, disk reads): threads are fine — the GVL releases during blocking I/O syscalls, so other threads run while one waits. - This is the runtime-level reason