thalarch-kotlin-migrationlisted

# Thalarch Kotlin Migration Migration is not transliteration. The first goal is preserved behavior and contracts; idiomatic Kotlin comes only after the faithful baseline is understood and verified. When an installed official Kotlin/JetBrains migration skill exactly matches the task, prefer that skill for platform-specific facts and use this skill as the acceptance/verification envelope. ## 1. Detect before converting For every file/package in scope, inspect imports, annotations, build plugins, and call sites to detect the frameworks/contracts that can change conversion semantics. Examples include: - Spring / dependency injection / proxy annotations; - JPA/Hibernate; - Jackson/serialization; - Dagger/Hilt/Guice; - Retrofit/OkHttp; - RxJava/coroutines; - JUnit/Mockito/test frameworks; - Lombok/generated members; - Java reflection/service loading; - public Java callers; - Android/Compose/KMP source sets. Load only the matching framework/platform guidance. Do not bulk-load unrelated migration rules. ## 2. Freeze migration invariants Before editing, write the invariants that must survive: 1. **Behavior** — same externally observable results, exceptions, side effects, ordering. 2. **API/interoperability** — Java/Kotlin callers still see compatible signatures where required. 3. **Nullability/mutability** — platform/null contracts and collection mutation semantics stay intentional. 4. **Framework semantics** — annotations, proxyability, constructor/lifecycle requirements