Skip to content

fix(tools): triage runs from a capture directory, which is the normal case - #116

Merged
craig-dt merged 1 commit into
mainfrom
fix/triage-runs-from-anywhere
Aug 17, 2026
Merged

fix(tools): triage runs from a capture directory, which is the normal case#116
craig-dt merged 1 commit into
mainfrom
fix/triage-runs-from-anywhere

Conversation

@craig-dt

Copy link
Copy Markdown
Collaborator

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:

labelling 12 capture(s), 8 at a time
  rules : /Users/…/flabel/.flabel/rules
  output: /Users/…/pcap-labeling/runs-267915ba4f708fc9

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

Sabotage Result
drop --project fails test_the_subprocess_is_pinned_to_the_checkout_and_an_absolute_rules_dir
rules dir relative again fails test_the_repo_is_found_from_the_script_not_the_cwd
label against a missing store fails test_an_absent_snapshot_store_refuses_rather_than_labelling_against_nothing

Testing

  • uv run pytest -q1053 passed, 5 skipped (was 1049/5; 4 new)
  • Run end to end from pcap-labeling/ against a capture in the repo — works, and reports the snapshot it used

🤖 Generated with Claude Code

… 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.
@craig-dt
craig-dt merged commit b38d1fc into main Aug 17, 2026
6 checks passed
@craig-dt
craig-dt deleted the fix/triage-runs-from-anywhere branch August 17, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant