What happened
A generated instance's Phase 3 build-troubleshooting note carried this instruction, under its JDK-version-mismatch failure mode:
If the sandbox blocks JDK discovery itself (e.g. ls /usr/lib/jvm denied because only the working directory is readable), that denial alone is sufficient grounds for UNVERIFIED — do not retry variations of a denied command.
During the 2026-08-29 cycle, ls /usr/lib/jvm was denied exactly as described, because the session sandbox restricts access to the target repository's own working directory. Read literally, the instruction was satisfied and the cycle had grounds to declare the anchor UNVERIFIED, mark the PR do-not-auto-merge and hand it to a human. That would have been wrong: the build was run anyway and succeeded — compile, full test suite and lint all green. The toolchain was selected without the probe and only an advisory line was emitted. A real local anchor was available the whole time.
Why it matters
The instruction inverts the diagnostic order. Environment discovery is a remedy for a build failure that has already been observed, not a precondition for attempting the build. Treating a denied probe as terminal lets an environment restriction with no bearing on the outcome decide the cycle's verification state, and the cost is asymmetric: a spurious UNVERIFIED defers a perfectly verifiable PR to a human, and does so silently, because nothing about the outcome looks like an error.
A denied probe is evidence about the probe, not about the tool it was meant to diagnose. The same shape applies to any environment probe a sandbox refuses.
This interacts with text PR #93 already landed. Phase 4's UNVERIFIED rule now names "the session sandbox restricts filesystem/tool access to only the target repo's own working directory — common in gardener-dispatched sessions" among the conditions under which the anchor cannot run. That is correct where the sandbox blocks the anchor itself, but a generated skill's per-tool troubleshooting note can read it as licensing UNVERIFIED whenever any command is refused for that reason — which is what happened here.
Suggested instruction text
State the ordering explicitly alongside the existing UNVERIFIED rule in Phase 4, and in the Step 4 guidance for authoring a project's build-troubleshooting notes:
Run the anchor before diagnosing the environment. A refused diagnostic command is not itself grounds for UNVERIFIED — the anchor is the build, so the build is what has to be attempted and seen to fail. Environment remedies (locating an interpreter or JDK, inspecting a tool home, checking an installed version) are responses to an observed anchor failure, and a sandbox denial on one of them only matters once that failure exists. Where a generated skill documents such remedies, they are ordered after the anchor's own invocation, not as a checklist to work through before it.
Generality
The specific text is in one instance's build-troubleshooting note, but the principle is not tool-specific and would apply to any project whose skill documents environment remedies for its build tool. A repo-specific correction to the offending sentence is expected to remain in that instance after the principle lands here; the two halves are being tracked separately.
Reported from the generated instance dmccoystephenson/medieval-factions-dev-loop, where it is tracked as issue #53.
This issue was filed during a Gardener session (https://github.com/Stephenson-Software/gardener).
drafted by Claude on behalf of Daniel Stephenson
What happened
A generated instance's Phase 3 build-troubleshooting note carried this instruction, under its JDK-version-mismatch failure mode:
During the 2026-08-29 cycle,
ls /usr/lib/jvmwas denied exactly as described, because the session sandbox restricts access to the target repository's own working directory. Read literally, the instruction was satisfied and the cycle had grounds to declare the anchor UNVERIFIED, mark the PR do-not-auto-merge and hand it to a human. That would have been wrong: the build was run anyway and succeeded — compile, full test suite and lint all green. The toolchain was selected without the probe and only an advisory line was emitted. A real local anchor was available the whole time.Why it matters
The instruction inverts the diagnostic order. Environment discovery is a remedy for a build failure that has already been observed, not a precondition for attempting the build. Treating a denied probe as terminal lets an environment restriction with no bearing on the outcome decide the cycle's verification state, and the cost is asymmetric: a spurious UNVERIFIED defers a perfectly verifiable PR to a human, and does so silently, because nothing about the outcome looks like an error.
A denied probe is evidence about the probe, not about the tool it was meant to diagnose. The same shape applies to any environment probe a sandbox refuses.
This interacts with text PR #93 already landed. Phase 4's UNVERIFIED rule now names "the session sandbox restricts filesystem/tool access to only the target repo's own working directory — common in gardener-dispatched sessions" among the conditions under which the anchor cannot run. That is correct where the sandbox blocks the anchor itself, but a generated skill's per-tool troubleshooting note can read it as licensing UNVERIFIED whenever any command is refused for that reason — which is what happened here.
Suggested instruction text
State the ordering explicitly alongside the existing UNVERIFIED rule in Phase 4, and in the Step 4 guidance for authoring a project's build-troubleshooting notes:
Generality
The specific text is in one instance's build-troubleshooting note, but the principle is not tool-specific and would apply to any project whose skill documents environment remedies for its build tool. A repo-specific correction to the offending sentence is expected to remain in that instance after the principle lands here; the two halves are being tracked separately.
Reported from the generated instance
dmccoystephenson/medieval-factions-dev-loop, where it is tracked as issue #53.This issue was filed during a Gardener session (https://github.com/Stephenson-Software/gardener).
drafted by Claude on behalf of Daniel Stephenson