[juliankang4]

What and why

The Labels workflow from #104 has not put a label on a pull request yet. Its first run, on #104's own merge
(run 38369104359), ended at the checkout:

allow-unsafe-pr-checkout: false
##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow. ...

The runs on #102 since then reached the script and ended at its first write with HTTP 403
(run 38370759755), at
call("POST", f"{base}/issues/{n}/labels", ...).

Three commits:

1. The checkout names no ref. On pull_request_target, github.sha is the default branch's head. After a merge
   made on GitHub that commit is the pull request's merge_commit_sha, and actions/checkout v7 refuses an explicit
   ref equal to it on a fork's pull request. With no ref, actions/checkout takes the same commit from the event
   and skips that check, which it runs only when the caller sets the repository or the ref
   (isDefaultCheckout in src/input-helper.ts). So the step keeps the same commit on every event and needs no
   opt-in.
2. A merge only adds labels. Once the merged run gets past the checkout, it labels the pull request from its
   merge commit against the first parent, and removes the bot's labels that diff does not ask for. A rebase merge,
   the only kind the merge button allows here, has no merge commit: merge_commit_sha is the pull request's last
   commit. A pull request with several commits would lose, at its merge, the labels its open runs put on for the
   earlier commits. The open runs already keep the labels in step with pulls/<n>/files, so the merge run now adds
   and removes nothing.
3. The job can write pull requests. A label on a pull request goes through issues/<n>/labels, and with
   issues: write and pull-requests: read GitHub refuses it with 403. The job now has pull-requests: write, as
   actions/labeler asks for the same call; issues: write stays for issues and for creating the labels.

I tried the other fix for 2, walking back from merge_commit_sha over the pull request's commits (by count, and by
subject as signals.py pr_commits does). It labels the stacks that were pushed at once wrongly: #27, #36, #38 and
#39 each list every commit below them, so each would take the whole stack's labels (#36 would get dgx-spark,
documentation, gpu, host, model, serve and tools instead of tools).

Code shape

• No second copy.
• Model code holds only architecture facts. Not model code.
• Dead code is gone.
• No silent failure. A merged run still fails by name on any API error; it only stops removing labels.
• Comments state what is true now.
• No relaxed gate. The self-test case for a merged pull request now expects the bot's stale labels to stay.
• cargo fmt and cargo clippy are clean on what I touched; the lint count did not go up. No Rust changed.

Duplication found or removed (path:line), or "none": none

What I ran

$ python3 -I tools/review/labels.py --self-test
labels.py self-test: ok
$ actionlint .github/workflows/labels.yml

With remove = [] if short else remove put back, the self-test fails on the merged case (serve comes off).

The stack figures above come from dry runs against this repository
(labels.py run --repo midagedev/bloomery --number N --dry-run) of the two walks I dropped, on the ten merged pull
requests with more than one commit. This change leaves the merge diff as it was, so the additions stay those of
3a21bf63 (#101 +dgx-spark +documentation +gpu, #39 +host +tools, run again at this head).

None of the three can run before the merge: the workflow runs from the default branch, so this pull request's own
runs use 3a21bf63 and fail the same way. Its close event is the first run with all three, and the next push to any
open pull request is the first open run.

Hardware (if the change is for a machine)

Not for a machine. Run on an arm64 Mac.

AI help

AI 코딩 에이전트가 코드를 작성한 후 설명을 썼고, 테스트를 마쳤습니다. diff 리뷰와 PR 초안 리뷰는 제가 직접 했습니다.

[github-actions]

Verdict: CLEAN: the change is two lines of workflow and one guard in labels.py, and every failure path I built is blocked.

Non-blocking

⚠ A merged run does not say it removed nothing: tools/review/labels.py:261. The "nothing removed" note prints only when short is set. For kind == "merged" the line reads unchanged while stale bot labels stay. A reader of the job summary cannot tell "nothing to remove" from "removal is off". Direction: print the same note when kind == "merged".

Checked

• Duplicates: 0 new functions; the change adds one condition to run. No dryer pairs (no Rust changed).
• Complexity: crapper did not run (no Rust). run gets one more or term, even growth.
• Silent failure: 1 site followed. remove = [] if short or kind == "merged" drops removals only. The POST of added labels still raises on any API error, so a 403 stays a named failure.
• Tests: the merged case in self_test protects labels.py:242. Mutant: put back remove = [] if short else remove. The case then expects {"tools"} | stale and serve comes off, so the assertion turns red (the author reports the same).
• Gates: no pin moved. The self-test expectation changed with the behavior, and the PR body gives the reason.
• Permissions: pull-requests: write is on a pull_request_target job, but the job checks out the base branch and runs only the base script; no PR code runs. The token is not persisted (persist-credentials: false).
• Escape catalog: C1 to C4 do not match. The shell step is unchanged.

Notes

• Not verified by static review: that actions/checkout v7 with no ref takes the base commit on pull_request_target and skips the merge-commit check. The PR body says only the close event can prove it.
• No GPU evidence applies; this is not a card change.

_{Not approved: this pull request changes .github/workflows/labels.yml, tools/review/labels.py, which changes the bot, CI or the toolchain and needs a person's approval.}

_{🔨 Shingler, bloomery's review bot: approves a clean pull request and requests changes on a must-fix (how it works)}

[juliankang4]

컨트리뷰트 체크 완료 했으니 머지합니다