The #194 multi-project guard cannot be run: docs/releasing.md step 4 invokes ./gradlew in samples/multiproject, which has no wrapper (exit 127)

[monkopedia-coder]

Code-health suggestion (proactive — staged for your review)

Category: test-gap

Where: docs/releasing.md:113 (local dry run, step 4) — and the absent samples/multiproject/gradlew

Current:

samples/multiproject is the #194 canary. Its own README says so in as many words:

That is [#194]: kplusplus 0.3.4 drove krapper over ksrpc (#185) … and every multi-project consumer died with NoSuchMethodError on its first kplusplusSync. … It shipped broken because every other sample is single-project … So: keep this sample two projects … That is the entire test.

:bindings:build is step 4 of the release local dry run (docs/releasing.md), which is where this sample is exercised. It has no CI workflow of its own.

So the whole verification budget for a bug that shipped and broke every multi-project consumer is one manual line in docs/releasing.md. That line is:

# 4. ...and that a MULTI-PROJECT consumer can drive the plugin at all (the #194 guard: ...)
(cd samples/multiproject && ./gradlew :bindings:build)

samples/multiproject has no Gradle wrapper. It was created in 0a5a705 (2026-07-29) with exactly six files and never had one, so that command has never been runnable. It does not fail the guard — it fails to reach it, with a shell error that looks like a typo:

$ cd /home/jmonk/git/kplusplus-wt/wt-health && for d in samples/minimal samples/multiproject samples/v8 .; do
>   printf '%-24s gradlew=%s  wrapperjar=%s\n' "$d" \
>     "$(test -x $d/gradlew && echo yes || echo NO)" \
>     "$(test -f $d/gradle/wrapper/gradle-wrapper.jar && echo yes || echo NO)"; done
samples/minimal          gradlew=yes  wrapperjar=yes     <-- positive control
samples/multiproject     gradlew=NO   wrapperjar=NO
samples/v8               gradlew=yes  wrapperjar=yes     <-- positive control
.                        gradlew=yes  wrapperjar=yes     <-- positive control

$ ( cd samples/multiproject && ./gradlew :bindings:build ) ; echo "exit=$?"
(eval):3: no such file or directory: ./gradlew
exit=127

And the fix is confirmed to be only the path prefix — samples/multiproject/README.md already uses ../../gradlew, and the repo-root wrapper drives this build correctly:

$ cd samples/multiproject && ../../gradlew projects --no-daemon
Root project 'multiproject'
\--- Project ':bindings'
BUILD SUCCESSFUL in 10s
exit=0

Also worth noting: steps 2 and 3 of the same dry run do work (samples/minimal has a wrapper), so a person following the runbook top-to-bottom gets three green steps and one no such file or directory — the most skippable-looking failure there is, at the one step that guards a shipped-broken release.

Proposed:

1. Fix the command in docs/releasing.md:113 to (cd samples/multiproject && ../../gradlew :bindings:build), matching samples/multiproject/README.md. (Or commit a wrapper to samples/multiproject, matching samples/minimal/samples/v8 — but the sample is deliberately not a standalone copy-paste consumer, so the prefix is the smaller, more honest change.)
2. Consider making the guard non-manual. samples-minimal.yml exists for exactly this reason on the other from-published sample; the 0.3.4: NoSuchMethodError in multi-project consumers — plugin classloader shadows coroutines to 1.8.0 #194 shape is not more expensive to run than the samples/minimal:nativeTest does not compile — property assignment vs generated accessor #195 one, and today the only difference between them is that one got a workflow and one got a sentence in a doc.

Why: #194 is the canonical "it shipped broken because nothing exercised the shape" defect in this repo, and the remedy it earned is a manual step whose command exits 127. A guard that cannot be invoked is indistinguishable from no guard, and this one has been in that state for the entire time it has existed (2026-07-29 → today), across two releases.

Effort: mechanical (the doc fix); small refactor (if a workflow is added)

Filed by the nightly code-health pass. To act on it: relabel agent-workable (it'll flow into triage→work). To decline: close it — it won't be suggested again.