Merged
Conversation
…s own composition `tests/test_case_divergence_298.py::test_the_per_tool_call_path_is_not_touched` was red on ubuntu-latest and macos-latest after #732 merged. The `_SANCTIONED_DIVERGENCE["scripts/lib-memory-dir.sh"]` entry for #662's `_LAZY_PYTHON_GUARD` insertion still pinned the pre-#726 two-argument python-fallback invocation as both its old_code and new_code, while #726 (shipped in #732) composed the guard directly into a three-argument invocation and never updated this older entry to match. Since origin/main only moves forward, neither shape is a substring of the real file, so the guard's own "neither old nor new" assertion fired. Remove the stale tuple: #726's own tuple already re-asserts the guard line as the first line of its new_code, so removing the redundant #662 entry loses no coverage of the guard-precedes-invocation invariant. Verified every remaining `_SANCTIONED_DIVERGENCE` entry (both files) resolves to new-present against current origin/main -- no other entry carries the same staleness risk right now. Closes #734 Co-Authored-By: Max <noreply>
…ple's removal Self-review (Explore reviewer) flagged that removing #662's own _SANCTIONED_DIVERGENCE tuple in 1cd7679 left two docstrings still citing "#429 and #662 both touch lib-memory-dir.sh" as the illustrative example of a file carrying more than one allowance. #662's guard insertion no longer has a standalone tuple -- it now only survives embedded inside #726's -- so #662 is no longer an accurate second example; #726 is. Updates both occurrences (tests/test_case_divergence_298.py and tests/test_sanctioned_divergence_state_440.py). Cosmetic/documentation only, no behavior change; targeted suite re-run green (26 passed). Co-Authored-By: Max <noreply>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was red
Push run 35448300892 on
mainat 7ba7609 (the squash merge of PR #732) failed everyubuntu-latest and macos-latest pytest leg in
tests/test_case_divergence_298.py::test_the_per_tool_call_path_is_not_touched, with:Windows legs pass (the module is
skipif'd on win32, pre-existing and untouched by thisdiff).
Root cause
_SANCTIONED_DIVERGENCE["scripts/lib-memory-dir.sh"]carried a #662 tuple pinning the_LAZY_PYTHON_GUARDinsertion into the no-jqelifbranch against a two-argument pythoninvocation. PR #732's own #726 fix changed the real script to a three-argument
invocation, composing the guard directly into it in one already-merged commit, without
updating the older #662 entry to match. Once #726 landed, neither the #662 tuple's
old_code nor its new_code was still a substring of
origin/main'sscripts/lib-memory-dir.sh-- exactly the "neither old nor new" failure the guardexists to raise.
Fix
Removed the stale #662 tuple entirely, replacing it with an explanatory comment. No
coverage is lost: the later #726 tuple's own new_code already carries the
_LAZY_PYTHON_GUARDline as its literal first line, so the "guard precedes the pythoninvocation" invariant #662 existed to pin is still asserted via that tuple's own
elif-branch match against
origin/main. Verified programmatically that all 11 remainingtuples across both files'
_SANCTIONED_DIVERGENCEentries resolve to "new-present"(already-shipped, no-op) against current
origin/main-- none stale.Also fixed a now-stale "#429 and #662 both touch lib-memory-dir.sh" cross-reference in
two files' prose (found in self-review), updated to "#429 and #726".
Tests
Red (fresh worktree cut from
origin/mainat 7ba7609, before any edit):python3 -m pytest tests/test_case_divergence_298.py::test_the_per_tool_call_path_is_not_touched -q-> 1 failed, matching the issue's quoted error string verbatim.
Green (after both commits):
python3 -m pytest tests/test_case_divergence_298.py tests/test_sanctioned_divergence_state_440.py -q --no-cov-> 26 passed, 0 failed.
Review
Two spawns (Explore, oss:auditor), concurrent, both told not to mutate. Tree snapshot
compare: clean. Explore found one cosmetic cross-reference finding (fixed, see above).
oss:auditor found 0 findings across all 4 checked classes and independently re-ran the
previously-failing test to confirm the fix is non-vacuous.
Closes #734.
[AI-generated]