Description
The repository prescribes a pull-request body shape and an issue-assignment convention, and enforces neither. Both live only in files that a contributor is trusted to have read.
.github/PULL_REQUEST_TEMPLATE.md specifies required sections (Summary, Changes, Testing, Footer), conditional ones (Related Issues and Pull Requests, Bugs Discovered), optional ones, and rules about each — Bugs Discovered is a pointer list of already-filed issue numbers with verbatim titles and nothing else, the Footer is a single line in one exact shape, and no new sections may be added. Nothing reads the pull-request body. A pull request that deletes every heading, or keeps the HTML comments as its content, or invents sections, passes CI exactly like one that follows the template.
Nothing checks assignment either. An issue can be worked, closed and settled with no assignee, and a pull request can be merged against an unassigned issue. This is not cosmetic here: Overflow reads claim state from the GitHub assignee, and available headroom is settled balance minus the reserve points of open issues assigned to outside contributors. An unassigned issue that someone is actually working reserves nothing, so the sponsor's headroom overstates what is genuinely available.
The two CI workflows the repository runs are ci.yml, whose only job is verify (migrations, tests, lint, typecheck, build), and actionlint.yml, which lints the workflows themselves. Neither reads github.event.pull_request.body and neither reads assignees; assignees appears in the tree exactly once, as an empty field in the issue template's front matter.
Expected Behavior
CI fails a pull request whose body does not follow the prescribed template, and flags an issue that is being worked or closed without an assignee.
Reproduction Steps
- Open a pull request whose body is a single word, with no template sections at all
- Observe that
verify and actionlint both pass and the pull request is mergeable
- Close an issue with no assignee and observe that nothing reports it
Environment / Context
Observed at commit 24092d1. Workflows present: .github/workflows/ci.yml and .github/workflows/actionlint.yml.
Discovered During
Session 870c0ab3-421d-4cda-9f0c-39bd0afb5e6f — reviewing what the repository's CI actually gates, 2026-09-05.
Suggested Fix
Unverified: a workflow on pull_request (types opened, edited, synchronize, reopened) reading github.event.pull_request.body from the environment could assert the required headings are present and that Footer matches its one-line shape. Assignment could be checked in the same workflow against the issues the body's closing keywords name, which is the set that matters, since those are the issues the merge will close.
Description
The repository prescribes a pull-request body shape and an issue-assignment convention, and enforces neither. Both live only in files that a contributor is trusted to have read.
.github/PULL_REQUEST_TEMPLATE.mdspecifies required sections (Summary,Changes,Testing,Footer), conditional ones (Related Issues and Pull Requests,Bugs Discovered), optional ones, and rules about each —Bugs Discoveredis a pointer list of already-filed issue numbers with verbatim titles and nothing else, theFooteris a single line in one exact shape, and no new sections may be added. Nothing reads the pull-request body. A pull request that deletes every heading, or keeps the HTML comments as its content, or invents sections, passes CI exactly like one that follows the template.Nothing checks assignment either. An issue can be worked, closed and settled with no assignee, and a pull request can be merged against an unassigned issue. This is not cosmetic here: Overflow reads claim state from the GitHub assignee, and available headroom is settled balance minus the reserve points of open issues assigned to outside contributors. An unassigned issue that someone is actually working reserves nothing, so the sponsor's headroom overstates what is genuinely available.
The two CI workflows the repository runs are
ci.yml, whose only job isverify(migrations, tests, lint, typecheck, build), andactionlint.yml, which lints the workflows themselves. Neither readsgithub.event.pull_request.bodyand neither reads assignees;assigneesappears in the tree exactly once, as an empty field in the issue template's front matter.Expected Behavior
CI fails a pull request whose body does not follow the prescribed template, and flags an issue that is being worked or closed without an assignee.
Reproduction Steps
verifyandactionlintboth pass and the pull request is mergeableEnvironment / Context
Observed at commit
24092d1. Workflows present:.github/workflows/ci.ymland.github/workflows/actionlint.yml.Discovered During
Session
870c0ab3-421d-4cda-9f0c-39bd0afb5e6f— reviewing what the repository's CI actually gates, 2026-09-05.Suggested Fix
Unverified: a workflow on
pull_request(typesopened,edited,synchronize,reopened) readinggithub.event.pull_request.bodyfrom the environment could assert the required headings are present and thatFootermatches its one-line shape. Assignment could be checked in the same workflow against the issues the body's closing keywords name, which is the set that matters, since those are the issues the merge will close.