policy: grade only open pull requests against the linked-issue policy

[Kartikey1306]

Closes #8

Problem

linked-issue-policy.yml is called from a byte-identical linked-issue.yml in 19 repositories, each on pull_request_target for [opened, edited, reopened, synchronize]. edited fires on closed and merged PRs too, and nothing — caller or reusable job — guards on the PR's state. So a body edit on a PR merged before the policy existed grades it and fails it. On 2026-09-14 that produced 50 failing runs across eos, eBoot and ebuild (26 / 13 / 11), every one on a merged or closed branch.

Three callers already carry the guard on their own copy (eos#154, eBoot#125, ebuild#144); the review on each asked for it to move here so the other 16 repositories get it too.

Change

One if: on the linked-issue job — github.event.pull_request.state == 'open' — with the reason in a comment. github.event in a reusable workflow is the caller's event. Open PRs are graded exactly as before; the steps are unchanged.

A test pins the parsed structure, not the text: the guard must be on the job — a step-level if would still start the job and report a status for a merged PR.

Verification

$ python -m unittest discover -s tests/community        # the command community-governance-tests.yml runs
Ran 20 tests in 0.015s
OK

# negative control 1: guard line deleted
FAIL: test_job_runs_only_for_open_pull_requests
Ran 20 tests — FAILED (failures=1)

# negative control 2: guard moved from the job onto its first step
FAIL: test_guard_is_on_the_job_not_on_a_step
FAIL: test_job_runs_only_for_open_pull_requests
Ran 20 tests — FAILED (failures=2)

# restored
Ran 20 tests — OK

Parsed structure asserted on the change itself: if on jobs.linked-issue, name and runs-on unchanged, the three steps unchanged in order.

After this lands

Callers pin uses: …@92cb596c… with policy_ref: 92cb596c…. Bumping both to this merge commit gives every caller the guard; eos#154, eBoot#125 and ebuild#144 then drop to no-ops and can be closed or reduced to the pin bump.

Not run

The guard has not been exercised end-to-end, and cannot be from this PR. A pull_request_target workflow runs from the base branch's copy, so no PR against this repository — or against any caller — can trigger a live edited event on a merged PR through the changed job. The evidence that it does what it claims is therefore indirect: the parsed structure (asserted by the new test), the if: expression being the standard GitHub Actions form, and the 26 eos / 13 eBoot / 11 ebuild runs of 2026-09-14 that were resolved branch by branch and that this guard would have skipped. The first real observation comes after merge, on the next body edit of a merged PR in a caller whose pin has been bumped. (Caveat carried over from #10, which was closed in favour of this PR.)

[Kartikey1306]

Ready for review — this PR has never had one, and it is the org-wide half of a fix three repos are already carrying locally.

Head 5a4456a, opened 09-14, unchanged since. Two files, +37: one if: on the linked-issue job, and the test that pins it.

Why it is here rather than in each caller. linked-issue-policy.yml is called from a byte-identical linked-issue.yml in 19 repositories, every one on pull_request_target for [opened, edited, reopened, synchronize]. edited fires on closed and merged pull requests too, and neither the caller nor this reusable job guarded on state, so a body edit on a PR merged before the policy existed graded it and failed it — 50 failing runs across three repos on 2026-09-14 (eos 26, eBoot 13, ebuild 11), every one on a merged or closed branch. eos#154, eBoot#125 and ebuild#144 each carry the guard on their own copy; the review on each asked for it to move here so the other 16 repositories get it too. Those three stay as they are — a caller-side guard is still correct, and this one does not make them redundant for repos that pin an older ref.

Verified at 5a4456a just now, the same command community-governance-tests.yml runs:

• python -m unittest discover -s tests/community — 20 tests, OK

The guard is checked two ways, and both were shown to fail without it — I removed the line and ran the suite rather than assuming:

• guard deleted → test_job_runs_only_for_open_pull_requests fails
• guard moved to a step instead of the job → test_guard_is_on_the_job_not_on_a_step and the first test fail

That second case is the one a substring check would pass and the one that matters: a step-level if still spins the job up and reports a status for a merged PR. The test parses the YAML and asserts on jobs.linked-issue.if, so a guard that lands on the wrong key is caught.

Not run here: the reusable workflow itself against a live pull_request_target event — github.event in a reusable workflow is the caller's event, which is why the guard reads github.event.pull_request.state, but I have verified that by reading the docs and the 50 runs, not by firing a merged-PR edit. The one check on this PR (policy / Policy / Linked Issue) is green.

yamllint reports two long lines and two warnings in this file; all four are on master already (line 28 there is line 36 here, moved down by the 8 lines this adds) and no workflow in this repo runs yamllint. Closes #8.