mir-backend-jvm-quarkuslisted

Make It Right (Quarkus module). Quarkus + Hibernate ORM / Panache + RESTEasy / Reactive Routes + SmallRye Mutiny reliability footguns specific to this framework stack. Covers: build-time DI / annotation processing (reflection for GraalVM native image must be registered with @RegisterForReflection or fails only at native runtime), blocking the Vert.x I/O thread on reactive routes (annotate blocking work @Blocking), Mutiny async composition pitfalls (blocking inside Uni/Multi pipelines), build-time vs runtime config key differences, Dev Services, and native-image gotchas (dynamic proxies, serialization, resources). Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-jvm (JVM runtime concerns: thread pools, virtual threads, GC, container heap, cold start, JMM visibility, ThreadLocal hygiene); this module only adds Quarkus library mechanics. TRIGGER only when the JVM backend stack is Quarkus — building, reviewing, or debugging a Quarkus REST resource, CDI bean, Panache entity, Mutiny pipeline, or n
anantbhandarkar/make-it-right · ★ 12 · API & Backend · score 83

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

# /mir-backend-jvm-quarkus · Make It Right (Quarkus) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-jvm` (JVM runtime model) → **this** (Quarkus library mechanics). Run the gates first; load the JVM runtime tier for threading, GC, and container-heap concerns; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (virtual-thread pinning, pool sizing, GC tuning, `-XX:MaxRAMPercentage`, ThreadLocal hygiene, JMM visibility) live in `mir-backend-jvm` — not here.** **Stack assumed:** Quarkus 3.x · CDI (ArC) · RESTEasy Reactive or Classic · Hibernate ORM with Panache · SmallRye Mutiny · GraalVM CE / Mandrel for native image. ## The Quarkus footguns AI walks into most ### 1. Build-time DI — missing beans fail at build, not runtime (mostly) Quarkus resolves CDI beans at build time using ArC (a build-time CDI implementation). Most injection errors surface as build failures, which is good. But AI regularly writes code that assumes runtime reflection is available, then ships a native image that fails on first deployment. ```java // WRONG — a class only accessed via reflection (e.g., Jackson deserialization target, // JPA converter, or a dynamically-loaded strategy) is silently excluded in native image public class PayloadConverter implements AttributeConverter<Payload, String> { ... } // RIGHT — register for reflection explicitly @RegisterForReflection public class PayloadConverter implements Att