KonsistScope

Receiver of a konsist { } block: Konsist's own query vocabulary, plus the three words katachi answers with.

Everything on the left of the dot is Konsist's — classes(), functions(), declarations(), withNameEndingWith(...) and the rest arrive through Konsist's KoScope and Konsist's list extensions, unchanged. What katachi replaces is the right of the dot: where Konsist would end a query with its own assertTrue, a konsist { } block ends it with must, mustNot or mustBeEmpty.

The reason is the report, not taste. assertTrue throws on the first rejection and says so in prose; katachi needs the rejected declarations themselves, because the first line of an [UnsatisfiedFileConstraint] block is a real path a reader can open. Collecting them is the only way a block that rejects four classes can produce four blocks pointing at four files. All twelve of Konsist's assertions are therefore shadowed below as compile errors — one declaration per spelling, so that classes().first().assertTrue { } and classes().asSequence().assertTrue { } cannot slip past a shadow written only for lists.

What this scope cannot do

• KoFileDeclaration.projectPath and moduleName are not usable here. The scope is built with scopeFromExternalDirectories, which Konsist documents as not resolving its own project root, so both are relative to whatever root Konsist inferred rather than to the project katachi walked. Use KoScope queries and the paths in the report instead.

• .kts files are never in the scope. Konsist 0.17.3 parses a file only when its name ends in .kt (File.isKotlinFile), so a build.gradle.kts or any other script inside what a constraint covers is invisible here however the layout was written. A rule about build scripts has to be written as a plain fileConstraint { } reading the text itself.

• assertArchitecture is not shadowed. It is a member extension of KoArchitectureAssertion, so it does not resolve from inside a konsist { } block at all — unless a block writes with(KoArchitectureCreator) { } to bring the dispatch receiver in. That spelling is the same escape as building a list outside the block, and it is not one katachi can close.

Example 1: every class in the covered files is internal

"is not exposed outside its feature".konsist {
    classes().must { it.hasInternalModifier }
}

Example 2: a query over every declaration, not just classes

konsist {
    declarations().mustNot { it.toString().contains("TODO") }
}