fix(tools): triage runs from a capture directory, which is the normal case - #116
Merged
Conversation
… case
Found by trying to hand the command to Craig. The captures live outside the
checkout by necessity — they carry real addresses and cannot be committed — so
"outside the repo" is where an operator will be standing, and that is the one
place the tool did not work.
Two faults, both from resolving against the cwd:
* `uv run flabel` with no --project resolves the environment from the working
directory and exits 2 ("No such file or directory").
* --rules-dir defaults to spec §12's relative `./.flabel/rules`, so even past
the first fault it would have looked for the snapshot store beside the
captures.
Both now resolve against the script's own location: REPO from __file__, an
absolute DEFAULT_RULES_DIR under it, `uv run --project <REPO>`, and cwd=REPO on
the subprocess. The header prints both paths, so which snapshot store was used
is on screen rather than assumed.
It also refuses when the store is absent instead of labelling against nothing.
Twenty captures against a missing store is twenty runs of nothing, each leaving a
directory, and the summary would report a tidy zero for every one of them —
which is exactly the shape this tool exists to refuse.
CREDIT WHERE IT IS DUE: the original failed LOUDLY. Exit 2 per capture, "1
capture(s) did not label", overall exit 1, and an empty summary rather than a
clean-looking one. That is the only reason this is a footnote and not an issue.
Verified by three sabotages: dropping --project, making the rules dir relative
again, and labelling against a missing store each fail the test named for it.
Tested: 1053 passed, 5 skipped (was 1049/5 — 4 new). ruff clean.
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.
Found by trying to hand the command to Craig.
The captures live outside the checkout by necessity — they carry real addresses and cannot be committed — so "outside the repo" is where an operator will be standing, and that is the one place the tool did not work.
Two faults, both from resolving against the cwd
uv run flabelwith no--projectresolves the environment from the working directory and exits 2,No such file or directory.--rules-dirdefaults to spec §12's relative./.flabel/rules, so even past the first fault it would have looked for the snapshot store beside the captures.Both now resolve against the script's own location:
REPOfrom__file__, an absoluteDEFAULT_RULES_DIRunder it,uv run --project <REPO>, andcwd=REPOon the subprocess. The header prints both paths, so which snapshot store was used is on screen rather than assumed:And it refuses an absent store
Twenty captures against a missing snapshot store is twenty runs of nothing, each leaving a directory, and the summary would report a tidy zero for every one of them — exactly the shape this tool exists to refuse. Now exits 2 with the path it looked in.
Credit where it is due
The original failed loudly: exit 2 per capture,
1 capture(s) did not label, overall exit 1, and an empty summary rather than a clean-looking one. That is the only reason this is a footnote rather than an issue.Verified by sabotage
--projecttest_the_subprocess_is_pinned_to_the_checkout_and_an_absolute_rules_dirtest_the_repo_is_found_from_the_script_not_the_cwdtest_an_absent_snapshot_store_refuses_rather_than_labelling_against_nothingTesting
uv run pytest -q→ 1053 passed, 5 skipped (was 1049/5; 4 new)pcap-labeling/against a capture in the repo — works, and reports the snapshot it used🤖 Generated with Claude Code