Why it exists
Nineteen Gradle builds had arrived at five ways of publishing, four wirings of ktlint and eleven different .editorconfig files. sborka is one plugin that settles those — the coordinate, the toolchain, publishing, the formatter, the test gate — and one line in gradle.properties instead of dozens of lines of Kotlin per repository.
kapkan is the second half: a ktlint rule set the conventions hand to ktlint, where each rule encodes one class of defect found in this stack rather than an opinion about style.
One line per decision
sborka.group=io.github.youndie
sborka.jvmToolchain=25
sborka.jvmFloor=25
sborka.junitVersion=6.1.3
The gate that reads the results
sborka.test compares the @Test methods a module declares with what JUnit reported. A test whose last expression returns a value is not a test — JUnit does not run it and does not warn — and three of them were found this way in one repository, two months old, one covering a defect that could zero a subscriber's remaining allowance.
Native and browser suites get the smaller half of the same question: a suite that ran nothing does not pass.
What kapkan catches
Three ktlint rules, each with the item it was found in — a platform's own package imported into common code, a failure nothing reads, code asking the machine it happens to run on what time it is — plus a guard that makes every suppression say why, and kapkanJoins: the declarations nothing outside their own file mentions and the functions nothing calls.
There is no configuration. A rule is in the set or it is not, and the only knob is a suppression that has to say why.