Gap found during a Phase 9 self-audit
Filed here rather than on dmccoystephenson/create-dev-loop-dev-loop, which does not resolve — see #87 and the same note on #109.
What was observed
The generated template's Phase 4 self-review rubric instructs, at create-dev-loop.md:351:
Tests-fix (empirical, not judged): for each bug fix, temporarily revert the fix (git stash push -- <src files>), run the new/changed tests and confirm they FAIL, then git stash pop and confirm they PASS.
By the time that rubric item is reached, Phase 3 has committed the fix and Phase 4 has pushed the branch and opened the PR. The working tree is therefore clean, and git stash push -- <src files> saves nothing. Running it during the cycle that produced PR #113 produced exactly that: the push was a silent no-op, the subsequent check ran against the unmodified (fixed) tree and passed, and git stash pop then failed with No stash entries found. Scored naively, that sequence reads as "reverted, still passed → false negative in the test", when in fact nothing was ever reverted.
The correct maneuver on a committed fix is the checkout form — git checkout origin/<default-branch> -- <src files>, run the check, then git checkout HEAD -- <src files> to restore — which was what actually produced a usable result.
Why the existing fallback text does not cover it
create-dev-loop.md:358 already documents the checkout form, but frames it as a retry for when stash fails for reasons unrelated to the tool or interpreter — "a dirty working tree, submodule state". That framing has the situation backwards. Stash is not failing here because the tree is dirty; it is failing because the tree is clean, which is the normal and expected state at Phase 4 rather than an anomaly. A reader following the rubric in order reaches the stash form first, and the fallback's stated triggers do not describe what they are about to see.
Suggested change
Make the checkout form the primary instruction in the Tests-fix rubric item, since it is correct in both states, and demote stash to the case where the fix is genuinely still uncommitted:
Tests-fix (empirical, not judged): for each bug fix, temporarily revert the fix — git checkout origin/{{DEFAULT_BRANCH}} -- <src files> if the fix is already committed (the normal case at this point in the cycle), git stash push -- <src files> if it is not — run the new/changed tests and confirm they FAIL, then restore (git checkout HEAD -- <src files> or git stash pop) and confirm they PASS.
The fallback-ladder paragraph at :358 would then lose its "retry with checkout first" preamble, since the retry becomes the default.
Retrofit note
Per CLAUDE.md's "Promoting a rule into the template" section, existing generated skills predate this and will keep carrying the stash-only wording until they are regenerated. This repository's own create-dev-loop-dev-loop skill is one of them: it carries <!-- template-version: c2736ea --> and its Tests-fix item names git stash push -- create-dev-loop.md with no checkout alternative at all.
This issue body was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
drafted by Claude on behalf of Daniel Stephenson
Gap found during a Phase 9 self-audit
Filed here rather than on
dmccoystephenson/create-dev-loop-dev-loop, which does not resolve — see #87 and the same note on #109.What was observed
The generated template's Phase 4 self-review rubric instructs, at
create-dev-loop.md:351:By the time that rubric item is reached, Phase 3 has committed the fix and Phase 4 has pushed the branch and opened the PR. The working tree is therefore clean, and
git stash push -- <src files>saves nothing. Running it during the cycle that produced PR #113 produced exactly that: the push was a silent no-op, the subsequent check ran against the unmodified (fixed) tree and passed, andgit stash popthen failed withNo stash entries found. Scored naively, that sequence reads as "reverted, still passed → false negative in the test", when in fact nothing was ever reverted.The correct maneuver on a committed fix is the checkout form —
git checkout origin/<default-branch> -- <src files>, run the check, thengit checkout HEAD -- <src files>to restore — which was what actually produced a usable result.Why the existing fallback text does not cover it
create-dev-loop.md:358already documents the checkout form, but frames it as a retry for when stash fails for reasons unrelated to the tool or interpreter — "a dirty working tree, submodule state". That framing has the situation backwards. Stash is not failing here because the tree is dirty; it is failing because the tree is clean, which is the normal and expected state at Phase 4 rather than an anomaly. A reader following the rubric in order reaches the stash form first, and the fallback's stated triggers do not describe what they are about to see.Suggested change
Make the checkout form the primary instruction in the Tests-fix rubric item, since it is correct in both states, and demote stash to the case where the fix is genuinely still uncommitted:
The fallback-ladder paragraph at
:358would then lose its "retry with checkout first" preamble, since the retry becomes the default.Retrofit note
Per
CLAUDE.md's "Promoting a rule into the template" section, existing generated skills predate this and will keep carrying the stash-only wording until they are regenerated. This repository's owncreate-dev-loop-dev-loopskill is one of them: it carries<!-- template-version: c2736ea -->and its Tests-fix item namesgit stash push -- create-dev-loop.mdwith no checkout alternative at all.This issue body was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
drafted by Claude on behalf of Daniel Stephenson