Kotlin port: var-kotlin authoring facade + var-kotest adapter over the Java engine

[aslakhellesoy]

Summary

The Kotlin port — unlike TypeScript→Python→Java, this does not re-port the pipeline: it layers an idiomatic Kotlin authoring API on the existing, conformance-green Java engine (the design decision the adding-a-language-port skill required writing down; see the spec).

Authoring looks like this — one top-level val per .steps.kt file, no class, state as the handler receiver:

data class Ctx(val cukes: Int = 0)

val steps = defineState(::Ctx) {
    context("I have {int} cukes") { n: Int -> copy(cukes = n) }
    action("I eat {int} cukes") { n: Int -> copy(cukes = cukes - n) }
    sensor("I should have {int} cukes left") { cukes }
}

What's in the box

• java/var-kotlin — the com.oselvar.varkt facade: defineState returns an inert, replayable StepDefinitions (no static accumulator — registration only happens when the runner replays the block against a fresh Registrar); StateBox bridges bare data classes into the engine's C extends State bound; suspend handlers from day one via runBlocking; custom parameterTypes.
• java/var-kotest — VarSpec : FunSpec(): subclass it, point the shared three config keys at your specs/steps, one Kotest test per planned example; failure rendering delegated to Render.renderFailure (span-anchored).
• var-junit works unmodified — the existing JUnit Platform engine drives Kotlin-authored steps end to end (proven by EngineTestKit smoke tests).
• Java-side enablers (Kotlin-agnostic): @RegistrarGlue so StackWalker source locations skip DSL glue frames and point at the author's .steps.kt; StepLoader now loads public static no-arg factory methods returning StepDefinitions (what a top-level val compiles to) and rejects two defineState registrations per source file.
• Conformance: 12 new *.steps.kt fixtures in the shared corpus, registry stage gated byte-for-byte against the committed goldens (goldens untouched); stem-compatible file names (numerals.steps.kt) need zero changes to Conformance.fileStem.

Design notes (recorded in the spec's Risks-RESOLVED section)

• The flagged zero-parameter-lambda overload ambiguity materialized (K2 rejects sensor("…") { cukes } with same-scope arity overloads). Resolved with a member/extension split (members win resolution for parameterless lambdas) plus arity-tolerant handler adapters (surplus captured args dropped, TS semantics) — the interview-approved API compiles and runs verbatim. Consequence: authors import context/action/sensor alongside defineState (IDE auto-import).
• @file:RegistrarGlue on the DSL file annotates the file-facade class so extension-registered steps still attribute to the author's file.

Testing

Full reactor (mvn -f java/pom.xml clean test): 351 tests, 0 failures across all six modules, including 12/12 registry conformance, both engine smokes (JUnit + Kotest), and the failure-rendering path through the real Kotest engine.

Docs: design spec (docs/superpowers/specs/2026-07-01-kotlin-facade-design.md, with resolved risks) + task plan. Known follow-ups (from the final review, deliberately post-merge): Kotest diagnostics parity with var-junit's ReportEntry, kotlin-maven-plugin pluginManagement + kotlin-reflect/coroutines pins, shared relPosix helper, CLAUDE.md repo-layout addition of java/.

🤖 Generated with Claude Code

https://claude.ai/code/session_017h1WEs7ReorF43DQsu4u4K