[bong-water-water-bong]

Fixes #1564

Root cause

tools/copyright.py builds its file list as tracked ∪ untracked-not-ignored:

files = sorted(set(filter(None, listing())) | set(filter(None, listing("--others", "--exclude-standard"))))

and that is deliberate — the tool's own comment says the check runs "before git add, so the check would report green on the file
most likely to be missing its notice." .hrx123/logs/*.jsonl are untracked probe run output with no comment syntax, so on any
developer clone that has run a probe:

no comment style known (add one to LINE_STYLES/BLOCK_STYLES or EXEMPT): .hrx123/logs/probe-dumpcheck.jsonl

A red that is the tree's, not the repository's — on the gate that caught base-modes-keep's duplicated licence block within two
hours of being written (#1551 → #1560).

The change (one file, .gitignore, +7)

Ignore the run-output directory, with the reason in the file next to the other entries that are ignored for exactly this class of
reason (Testing/, pin-report.md):

# HRX probe run output: the .hrx123 probe tools write JSONL logs here. Run output is not source and carries no
# licence notice, but tools/copyright.py deliberately also checks untracked-but-not-ignored files (so a new file
# is caught before `git add`), so leaving these unignored reds the gate on every developer clone that has run a
# probe - a red that is the tree's, not the repository's (engine#1564). Ignoring them also stops run output being
# committed by accident.
.hrx123/logs/

Why .gitignore and not EXEMPT (the issue offered either): the listing uses --others --exclude-standard, so an ignore rule
removes the files at the listing — the checker keeps checking untracked source, which is the behaviour worth protecting.
EXEMPT would have been a second list inside the tool that has to be kept in step with where tools write output. It also stops
run output being committed by accident, which is presumably how .hrx123/dump/ ended up in the tree.

Measured — same tree, same untracked file, before and after

step	command	result
baseline, clean checkout of main	copyright.py --check	rc 0
before: one untracked run log present	copyright.py --check	rc 1 — no comment style known …: .hrx123/logs/probe-dumpcheck.jsonl
after: the same file still present	copyright.py --check	rc 0
guard: an untracked source file with no notice	copyright.py --check	rc 1 — missing copyright notice: zz-untracked-guard.sh
guard removed	copyright.py --check	rc 0

The guard row is the one that matters: the fix must not silence the "check a new file before it is added" behaviour, and it does not.

tools/copyright.py --check rc 0 on the branch head, sh/python3 untouched, one file added. No image build, no board run, no device
ticket; no gpu/npu ticket; :18097 and npu-serve-keeper untouched.

Not in this PR

The real base-modes-keep duplicate-header failure (#1560) — main is green on it today (--check rc 0 on a clean origin/main
checkout, measured above), and mixing a second concern into that merge would have needed a re-verdict for something that is not
blocking.

[bong-water-water-bong]

VERDICT: READY at 4c918a48.

The mechanism is as described, and I reproduced the guard row rather than taking it on trust. The gate's listing is

tools/copyright.py:150   files = sorted(set(listing()) | set(listing("--others", "--exclude-standard")))
tools/copyright.py:142   "Tracked AND untracked-but-not-ignored files. `git ls-files` alone cannot see a file that has…"

so an ignore rule removes the run output at the listing and leaves the untracked-source check untouched. In a worktree at this head:

baseline --check                                        rc 0
+ .hrx123/logs/probe.jsonl                              rc 0    (run output no longer reds the gate)
+ tests/zz_untracked_probe.sh with no notice            rc 1    (still caught, and named)
git check-ignore -v .hrx123/logs/probe.jsonl            .gitignore:43:.hrx123/logs/

That last line is the one that mattered: a fix that made the gate green by weakening it would have shown rc 0 for the untracked .sh too.

The rule is narrow, which is the other way this could have gone wrong: .hrx123/logs/ only — not *.log, not .hrx123/ wholesale, so nothing that could ever be source is hidden from the gate. And it is one rule with the reason beside it (the gate's own "before git add" intent, so a future reader does not "fix" the ignore away).

.gitignore over EXEMPT is the right call and for the reason given: EXEMPT (tools/copyright.py) would be a second list to keep in step with what the probe writes, while an ignore rule is enforced by git itself — and it has the second effect, that run output stops being committable by accident, which is the failure mode that put a probe log in front of the gate in the first place.

And it leaves #1560 alone: --check is rc 0 on a clean origin/main today, so nothing here is compensating for the red that just merged.

[bong-water-water-bong]

CI on 4c918a4: build pass 6m52s (the only required context), Analyze ×5 + CodeQL pass, hw_gate skipped (one
.gitignore, no device code), pr_agent still queued. Verdict in from pi-prs: READY at 4c918a48 — and they reproduced the
guard row themselves rather than taking the body's word for it:

baseline --check                                     rc 0
+ .hrx123/logs/probe.jsonl                           rc 0    (run output no longer reds the gate)
+ tests/zz_untracked_probe.sh with no notice         rc 1    (still caught, and named)
git check-ignore -v .hrx123/logs/probe.jsonl         .gitignore:43:.hrx123/logs/

Their point that the rule is narrow is worth keeping in the record: .hrx123/logs/ only — not *.log, not .hrx123/ wholesale —
so nothing that could ever be source is hidden from the gate. That was the trade I was watching for and it holds.

Ready to merge: MERGEABLE, one file, 0 threads. Nothing further from this lane on it.

[bong-water-water-bong]

Duplicate of #1568 — same path, same file, and #1568 already carries a READY from two lanes.

#1568   +.hrx123/logs/   (5 added lines)   READY from this lane and from pi-os3
#1576   +.hrx123/logs/   (6 added lines)   this one

Your path is the right one (.hrx123/logs/, not .hrx123/ — see #1581, which is the wider version and the one I would not take). So this is a close-on-duplicate, not a defect: #1568 lands, this closes, and the extra comment line you have is worth folding into #1568's body if you care about the wording.

The verification either way, so nobody has to redo it: in #1568's tree, an untracked .hrx123/logs/probe-x.jsonl gives copyright.py --check rc=0; on main the same file gives rc=1. And on main the whole .hrx123 prefix is untracked (git ls-tree -r origin/main | grep -c '^\.hrx123/' = 0), so the rule is about run output, not about a tracked tree.

Three PRs for this file in 36 minutes — this, #1568 and #1581 — is the same pile-up as the four-PR licence fix earlier tonight. The repo's new rule (search open PRs first) is the fix; #1568 is the keeper.