bug(adopter-preflight): the path-α push grade does not read protected_file_patterns, so its pass line may not hold #1570

New issue

Open

opened 2026-10-06 21:12:04 +02:00 by claude · 0 comments

claude commented

2026-10-06 21:12:04 +02:00

Member

Since #1482, rt adopter-preflight grades the path-α manifest push from four fields of the default branch's protection: enable_push, enable_push_whitelist, push_whitelist_usernames and push_whitelist_teams. Branch protection has another field that can refuse a push, protected_file_patterns. Neither rt adopter-preflight nor forgejo.BranchProtection reads it. A grep of internal/ and cmd/ for protected_file finds nothing (9048da0).

Why it matters

If an adopter's patterns match a file the cut commits, such as .release-toolkit-manifest.json or CHANGELOG.md, the manifest push may be refused. Meanwhile the preflight prints push: pass — token present AND "<bot>" may push to "main". That would be #1482's shape again: a pass line naming a capability the branch does not grant.

Not measured: a hypothesis (AGENTS.md §9)

Whether Forgejo applies protected_file_patterns to a whitelisted pusher has not been measured. Nobody has checked whether it refuses a whitelisted bot's push that touches a matching file. Nor whether unprotected_file_patterns changes the answer. Measure on a throwaway repo before choosing a fix, and read back the protection after writing it (AGENTS.md §8, Axis A).

Decision tree

If the patterns refuse a whitelisted push: read the field. Grade it against the files a cut commits, and FAIL on a match.
If they do not: add a disclosure line saying the field is not read and why that is safe, so the pass line stays honest.

Acceptance criteria

Measured on a throwaway repo: does a matching protected_file_patterns entry refuse a whitelisted user's direct push? Record the forge version and the read-back.
Depending on that answer, the push grade either FAILs on a pattern matching a file the cut commits, or names the field as not read
A test pinning whichever behaviour lands

Refs #1482 (follow-up from review 7284 on #1568)

Since #1482, `rt adopter-preflight` grades the path-α manifest push from four fields of the default branch's protection: `enable_push`, `enable_push_whitelist`, `push_whitelist_usernames` and `push_whitelist_teams`. Branch protection has another field that can refuse a push, `protected_file_patterns`. Neither `rt adopter-preflight` nor `forgejo.BranchProtection` reads it. A grep of `internal/` and `cmd/` for `protected_file` finds nothing (`9048da0`). ## Why it matters If an adopter's patterns match a file the cut commits, such as `.release-toolkit-manifest.json` or `CHANGELOG.md`, the manifest push may be refused. Meanwhile the preflight prints `push: pass — token present AND "<bot>" may push to "main"`. That would be #1482's shape again: a pass line naming a capability the branch does not grant. ## Not measured: a hypothesis (AGENTS.md §9) Whether Forgejo applies `protected_file_patterns` to a **whitelisted** pusher has not been measured. Nobody has checked whether it refuses a whitelisted bot's push that touches a matching file. Nor whether `unprotected_file_patterns` changes the answer. Measure on a throwaway repo before choosing a fix, and read back the protection after writing it (AGENTS.md §8, Axis A). ## Decision tree - If the patterns refuse a whitelisted push: read the field. Grade it against the files a cut commits, and FAIL on a match. - If they do not: add a disclosure line saying the field is not read and why that is safe, so the pass line stays honest. ## Acceptance criteria - [ ] Measured on a throwaway repo: does a matching `protected_file_patterns` entry refuse a whitelisted user's direct push? Record the forge version and the read-back. - [ ] Depending on that answer, the push grade either FAILs on a pattern matching a file the cut commits, or names the field as not read - [ ] A test pinning whichever behaviour lands Refs #1482 (follow-up from review 7284 on #1568)

claude added the

labels

2026-10-06 21:12:04 +02:00

claude referenced this issue

2026-10-06 21:12:09 +02:00

bug(adopter-preflight): reports path α available from a credential check, not from whether the push can land #1482