Greptile Summary

This PR reverts merge commit 56df8d3 from PR #707, restoring the previous lockfile management strategy: PRs may not include pnpm-lock.yaml changes, and a post-merge workflow on master regenerates the lockfile and opens a dedicated chore/refresh-lockfile PR when changes are detected.

Key changes:

• refresh-lockfile-pr.yml removed — the per-PR auto-commit bot introduced in ci: refresh pnpm lockfile before merge #707 is deleted.
• refresh-lockfile.yml restored — the push-to-master-triggered workflow that creates a chore/refresh-lockfile PR is re-added.
• pr-policy.yml updated — replaces the gh api-based changed-file detection with git diff, splits the logic into two steps (block lockfile edits, validate manifest resolution), and adds a branch-name exemption for the bot PR.
• pr-verify.yml — switches to --no-frozen-lockfile since PRs can no longer carry an updated lockfile.
• doc/DEVELOPING.md — updates the policy description, but the final bullet inaccurately mentions a --frozen-lockfile verification pass that does not exist in the restored workflow.

The one substantive issue is the branch-name guard in pr-policy.yml: the chore/refresh-lockfile exemption relies solely on github.head_ref, which any fork contributor can set to that value. Adding a same-repo check (github.event.pull_request.head.repo.full_name == github.repository) would close the bypass.

Confidence Score: 3/5

• Safe to merge after addressing the branch-name bypass in pr-policy.yml; the revert logic itself is sound.
• The revert correctly restores the previous workflow structure and the overall policy design is coherent. The one logic issue — the chore/refresh-lockfile exemption relying solely on branch name — is a meaningful security gap that allows a fork contributor to bypass the lockfile-edit block by naming their branch accordingly. The documentation inaccuracy is minor but adds confusion. Neither issue would break CI under normal circumstances, but the bypass warrants a fix before merging.
• pr-policy.yml — the branch-name-only guard on line 35 needs an additional same-repo check.

Important Files Changed

This is a comment left during a code review.
Path: .github/workflows/pr-policy.yml
Line: 35

Comment:
**Branch-name bypass allows arbitrary lockfile commits**

The condition `github.head_ref != 'chore/refresh-lockfile'` is intended to exempt the bot's auto-generated PR from the lockfile block, but `github.head_ref` is just the source branch name and is fully controlled by the PR author. Any external contributor can name their fork branch `chore/refresh-lockfile` and commit arbitrary changes to `pnpm-lock.yaml` without triggering this check, bypassing the policy entirely.

The guard should additionally verify the PR originates from the same repository (i.e. is not a fork):

```suggestion
        if: github.head_ref != 'chore/refresh-lockfile' || github.event.pull_request.head.repo.full_name != github.repository
```

With this fix the exemption only fires when the branch name matches **and** the PR comes from the canonical repo (i.e. the real bot PR), so fork-originated PRs from a branch named `chore/refresh-lockfile` are still subject to the lockfile-edit block.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: doc/DEVELOPING.md
Line: 24

Comment:
**Documentation does not match the actual workflow**

The line states that pushes to `master` "run verification with `--frozen-lockfile`", but the actual `refresh-lockfile.yml` workflow only regenerates the lockfile and opens a PR — it never runs a frozen install. Additionally, `pr-verify.yml` was changed in this same PR to use `--no-frozen-lockfile` for all PRs (including the `chore/refresh-lockfile` PR). The `--frozen-lockfile` verification step described here does not exist anywhere in the current CI setup.

```suggestion
- Pushes to `master` regenerate `pnpm-lock.yaml` with `pnpm install --lockfile-only --no-frozen-lockfile` and open a `chore/refresh-lockfile` PR if the lockfile changed.
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: b888f92}