docs: describe the boundary check that actually ships

[mustafayigitt]

The follow-up deliberately left out of #26. That PR generalized module-boundary enforcement from :app to every library module; six documents still described the narrower check. Docs written against proven behaviour rather than intended behaviour, which is the whole reason they were held back.

No code changes. Six files.

wiki/07

Finding 8 was the stale one. It read "Module-graph enforcement stops at :app". That gap is closed, so instead of deleting the row it now states the gap that remains: the check reads Kotlin import lines, so a project(":…") line in a build script still couples two modules invisibly to it. The finding keeps its number and its impact tier, because the risk did not disappear — it got smaller and more specific.

Remediation 6 records which half shipped and which did not, and adds a constraint discovered the hard way: a build-file check has to reason about dependency direction, not just pattern-match, because a reverse edge into an always-present module is also how a Gradle task-graph cycle gets created.

A new decision-log entry carries the rule table, why the feature.*.navigation.* exception is existing design rather than a loophole added to keep the build green, the per-module escape hatch, and how the check was proven by deliberately breaking it — including the control case, the two probe lessons, and why the failure report travels in the exception message instead of logger.error.

Remediation 3 gains the CancellationException note. A broad catch in safeCall must rethrow it before mapping anything else, or a cancelled coroutine is silently converted into a failed Result and the caller treats teardown as an error. Adding a broad catch without that line makes the code worse, not better.

Three risks added (18–20) that were true for a while but unstated:

• the CI plug-out job deletes 4 of roughly 12 optional modules; the rest satisfy the rule but are never actually deleted and rebuilt, so they are argued rather than demonstrated;
• mkdocs build --strict is not a pull-request check, so a broken link fails after merge, once it is already public;
• main is unprotected, and a fast merge can outrun CI entirely — docs: correct stale claims in project context and wiki index #25 was merged about a minute after opening and none of its checks ran.

Two corrections rather than additions:

• Finding 3 no longer claims "5 unit tests". That number was never re-derived from the tree, and I am not going to restate a figure I cannot defend. It now names the two test classes that demonstrably exist, BaseRepositoryTest and TokenAuthenticatorTest, which is the part that supports the finding anyway.
• The fifth open question — should the plug-out job also delete benchmark/ and baselineprofile/ — is removed. feat: make baseline profile tooling pluggable via composetemplate.perf #23 did exactly that; the question had been answered by the CI file for several PRs while still being asked on the page.

Finding 11 picks up the empty-module observation (feature/home/domain has a build.gradle.kts and no sources), since it is the same question the row already asks. Finding 16 now separates what CI proves — the performance tooling is removable — from what it does not: that a benchmark ever runs.

wiki/00, wiki/01, wiki/README.md

Convention plugin count 19 → 20 in all three places it appears. wiki/07 is now 20 findings.

wiki/00 had an entry under "Opinions the code does not enforce" reading "Feature-to-feature isolation is unchecked. The boundary task inspects :app only, so one feature importing another compiles happily." That was outright wrong after #26, and wrong in the most misleading direction — telling a reader a guardrail is absent when it will fail their build. Replaced with what is genuinely still unenforced: build-file coupling, removability being proven for only four modules, and the unprotected main.

wiki/01 gains the 44-library-module figure, since that is the set the check covers and it is not the same as the 47-module inventory.

wiki/08

Adds :core:data:checkModuleBoundary and :feature:auth:presentation:checkModuleBoundary next to the existing app command, plus the escape hatch in the "Removing what you do not need" section. Records that ktlintCheck does not trigger preBuild, so a lint-only run will not surface a violation — a genuine surprise if you are trying to reproduce a red pipeline locally.

build-logic/README.md

Documents composetemplate.module.boundary, notes that composetemplate.android.library applies it, and updates the file tree (CheckAppModuleBoundaryTask.kt is gone; CheckModuleBoundaryTask.kt and ModuleBoundaryPlugin.kt are new).

Also fixes ~48 modules, which has been 47 since module discovery landed. Small, but it is the kind of number a reader trusts precisely because nobody would bother to fake it.

What is not here

• last-updated / version stamps. Automating them needs fetch-depth: 0 in pages.yml, which needs workflow write. Content freshness first.
• A docs-freshness CI assertion. Same reason.
• The remaining wiki/07 items awaiting a decision rather than an edit: reprioritizing finding 4 (pick one serialization stack), reframing finding 1, and raising finding 9.

Verification

CI on a docs-only change produces a cache-heavy green run that verifies nothing about the documents themselves. The claim worth checking is that the rule table, task names, report paths and the escape-hatch snippet match ModuleBoundaryPlugin.kt and CheckModuleBoundaryTask.kt as merged — every one of them was copied from the source on main, not from the PR description of #26.

mkdocs build --strict is not a pull-request check (finding 19), so the internal links added here — the #baseline-decision-log anchor in particular — are unverified until the site rebuilds after merge.