Twinned from https://github.com/cfsh/ninefold/issues/446 by tools/beads/import_github.py's reconcile pass.
Suggestions from ninefold-reviewer's review of #436. All three are below the gate's severity floor — #436 is CONVERGED and nothing here blocks it. Filed so the tension lives in the tracker rather than in the PR thread. Unclaimed and unlabelled.
tools/tests/test_presubmit.py:277 — test_list_renders_an_unenumerable_lane_instead_of_crashing says *"Driven as a subprocess so the real argparse/main path executes"*, but the body monkeypatches presubmit.tracked_shell_scripts and calls presubmit.main([...]) under contextlib.redirect_stdout. That is the right test — it pins the renderer, which is the half that matters — but the docstring describes a different one.
The sibling that *is* a subprocess, test_list_end_to_end_with_a_broken_git_exits_zero (:302), never reaches the None state: PRESUBMIT_BASE=refs/nf-does-not-exist breaks changed_files(), not git ls-files, so all_scripts() returns a real list and shellcheck gets 16 paths. So no test drives C5's bug across a process boundary, and a docstring says one does.
Fix is either wording (drop the sentence) or a real subprocess case that breaks git ls-files. In a PR whose theme is *a claim must match what actually ran*, the wording fix alone is probably not the satisfying one.
CLAUDE.md:210–225 documents the presubmit gate's head checkout and its tracked-only refusal, but not the third path #436 C8 added: a PR head that predates presubmit.py prints
``` note: #<n>'s head (<sha>) predates the presubmit gate — nothing to run. Rebase onto main to gate it. The post-merge UI gate still runs. ```
and merges ungated. That is the correct behaviour, and the message is self-explanatory — but it will fire on the next three merges (#434/#435/#437 all have pre-gate heads), and a session that has read the section will have been told the gate "refuses to merge if it fails" with no sentence covering "or quietly runs nothing". One line in the same bullet closes it.
tools/pr/merge_pr.sh:194 — the whole checkout block, including the git diff --quiet HEAD refusal at :203, is inside if [ "$here_sha" != "$head_sha" ]. Running merge_pr.sh from the PR branch with uncommitted tracked changes therefore gates head + your working tree while printing presubmit PASSED against #<n> head <sha>.
Narrower than F1 (the tree does contain the change, plus extra) and the operator is the author, so the usual direction is harmless. But the one case that bites is uncommitted work that *masks* a failure at the head — a red PR merging behind a green report, which is exactly the direction F1 was fixed to close. A git diff --quiet HEAD check hoisted above the if, or a (+ uncommitted changes) suffix on the pass line, would make the claim true in both branches.
None.
No comments.