Development record
2026-10-30 — Decided by the technical facilitator, on delegation, for iss-2610290913450522: the remote audit pins each required check to the one GitHub App observed reporting it in the check runs of the default branch's three newest commits and the three newest pull requests' heads, by the app id GitHub's answer names, never a hard-coded one. A check two apps or a commit status reported, or no recent run reported, stays required from any source and is named; a read that fails or is cut short pins nothing; an existing pin is never changed; pinning a check already required from any source is a tightening applied only on the apply's yes. Grounds: GitHub's rulesets documentation says any person or integration with write access can set the state of any status check, and that a rule may name an app as a check's expected source (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets); the rules REST API takes that source as a required check's optional integration_id (https://docs.github.com/en/rest/repos/rules); and push access is enough to post a commit status (https://docs.github.com/en/rest/commits/statuses). Assessed against abcd-fixes-what-it-adds: the any-source route is GitHub's default and exists without abcd, so this is hardening of a protection abcd writes, not a weakness it adds.
2026-10-30 — Decided by the technical facilitator, on delegation, for iss-2610290913450522: the remote audit pins each required check to the one GitHub App observed reporting it in the check runs of the default branch's three newest commits and the three newest pull requests' heads, by the app id GitHub's answer names, never a hard-coded one. A check two apps or a commit status reported, or no recent run reported, stays required from any source and is named; a read that fails or is cut short pins nothing; an existing pin is never changed; pinning a check already required from any source is a tightening applied only on the apply's yes. Grounds: GitHub's rulesets documentation says any person or integration with write access can set the state of any status check, and that a rule may name an app as a check's expected source (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets); the rules REST API takes that source as a required check's optional integration_id (https://docs.github.com/en/rest/repos/rules); and push access is enough to post a commit status (https://docs.github.com/en/rest/commits/statuses). Assessed against abcd-fixes-what-it-adds: the any-source route is GitHub's default and exists without abcd, so this is hardening of a protection abcd writes, not a weakness it adds.
Frontmatter
| id | dcn-2610300713175316 |
|---|---|
| type | decision |
| date | 2026-10-30 |
.abcd/work/decisions/dcn-2610300713175316-decided-by-the-technical-facilitator-on.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2610290913450522The settings baseline requires each status check from any source. GitHub lets any person or integration with write access set the state of any status check, and the statuses API lets a push-access token post any context, so a required check left on any source can be set to passing by someone other than the workflow that runs it. Choosing the app as the source refuses a status set by anyone else. Assessed against the abcd-fixes-what-it-adds principle: the route exists without abcd (it is GitHub's default for any required check), and abcd's apply adds no weaker state, since without it the repository requires no check at all; pinning is a tightening of a setting abcd itself writes, applied only on the person's yes, and changes nothing else about how the repository works. No released abcd has ever applied a required check: the apply that writes one ships for the first time in the change itd-2610290746077716 delivers, so abcd has put no managed repository in this state.