story-046: The test location comes from configuration - #44
Merged
Conversation
Implemented by the l5 harness story workflow.
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
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.
workflows/story-workflow.jsondeclared"may_not_create": ["tests/"], andprompts/tester.mdtold the tester that new tests belong intests/and to use the shared resolution intests/conftest.py. Those are a target repository's layout and a target repository's test framework, written into the harness. A JavaScript project puts tests in__tests__/orspec/; a Go project has none at all —_test.gofiles sit beside their sources.What changed
A
tests_dirkey, and the workflow references it:The placeholder is resolved when the workflow loads, so
stage_restrictionsand its six readers — the ownership check, the revert check's governed edits, the stage-baseline capture,stage_exception_problemsand both ofplan_validation's checks — are untouched.harness_config.load_workflowreturnsmay_not_create: ['tests/']for this repository exactly as before.tests_diris declared inschemas/harness-config.schema.json, so story-039's set-equality coverage holds and story-043's undeclared-key refusal accepts it. The tester prompt takes the location by injection rather than restating it.This closes the portability audit
Story-040 split the scan's allowlist into a temporary half that should burn down and a permanent half that should not, and said the temporary half reaching empty was the completion signal. It is empty.
The scan still reports eight findings, and every one is a
PERMANENT_MENTION: five shebangs declaring the harness's own entry points as Python programs, and two docstrings describing the harness's own implementation. Not one is a tie to a target's stack.Five ties were found by the audit on 2026-08-15.
the-interpreter-is-not-assumed-to-be-pythonremoved two,an-undeclared-config-key-is-refusedremoved the literal that survived them, and this removes the last three.The retry is worth reading
Verification failed once and routed to
validation. The finding is one the request predicted and the tester still walked into: three assertions readTEMPORARY_TIESto decide something, and with the list emptied tofrozenset()none of them could fail. An assertion written against "the burn-down still has entries" fails on success.Resolved by reading the scan rather than the list, and by keeping one removed tie verbatim as a control:
so "the coordinator carries no temporary tie" is demonstrable rather than vacuous.
Verification
2408 passed, 4 written; verification passed on the second iteration; one retry, routed tovalidation; clean-clone green with the story committed🤖 Generated with Claude Code