Repository navigation
Onboard proven external contributors via OWNERS-file reviewers to unblock automated review dispatch #1531
Description
What happened
Review-stage dispatch only auto-fires on pull_request_target opened/synchronize/ready_for_review when the PR author has at least triage-level repo permission (reusable-dispatch.yml's is_event_actor_authorized "${PR_USER_LOGIN}" triage, per ADR 0054). External contributor guyoron1 (https://github.com/guyoron1) holds only the public-repo default 'read' role (confirmed via gh api repos/fullsend-ai/agents/collaborators/guyoron1/permission), so every one of their PRs is routed with an empty stage and never gets a fullsend review comment. A GraphQL search (repo:fullsend-ai/agents author:guyoron1 is:pr) shows 16 PRs since 2026-07-21: only 2 merged, 8 currently open, several 1-2 months old. PR #1246 (#1246) is a concrete casualty: opened 2026-09-10, sat 18 days with no review-agent comment, no human review, and no third-party bot comment either (Qodo did comment on the stacked parent PR #1245 but not on #1246), then was closed unmerged by the author on 2026-09-28. Two more contributors — Benkapner (3 open PRs) and amastbau (1 open PR) — hold only 'read' permission too and are subject to the identical gap (gh pr list --repo fullsend-ai/agents --state open --json number,author -q 'group_by(.author.login)...'). The platform already ships a mitigation for exactly this case: an opt-in OWNERS-file authorization provider (documented in ADR 0054's 2026-08-10 addendum from fullsend-ai/fullsend#6042) where a repo-root OWNERS file's reviewers: list grants triage-equivalent access without granting write/merge rights. fullsend-ai/agents has neither an OWNERS file nor the authorization: [{provider: owners_file}] block in .fullsend/config.yaml today — the mechanism is simply unused here.
What could go better
I'm confident about the mechanism and the data (permission levels, PR counts, and the missing OWNERS/config.yaml block are all directly verified against the repo and GitHub API). I'm less certain about the right list of names to onboard — that's a maintainer trust judgment, not something a retro should decide unilaterally, so I'm proposing the mechanism and citing guyoron1 as the clearest evidence rather than mandating a specific roster. I checked for duplicates: the general external-contributor review-gap is already tracked upstream in fullsend-ai/fullsend (#4374, #2967, #5154, #6802, #2552 — the last one actually argues the opposite direction, for deferring review on untrusted external PRs), so I did not re-propose relaxing the platform-wide gate. This proposal is narrower and does not wait on any of those: it uses a mechanism that already exists and only asks fullsend-ai/agents to configure it for itself.
Proposed change
Add a repo-root OWNERS file to fullsend-ai/agents with a reviewers: list naming a small number of contributors with a demonstrated track record of high-quality, well-tested PRs (guyoron1 is the clearest candidate: 2 merged PRs, and commit messages across the #1245/#1246 series show careful ADR references, production-data-backed design rationale, and thorough test coverage). Add the corresponding authorization: - provider: owners_file entry to .fullsend/config.yaml per the documented v1 opt-in (flat repo-root approvers/reviewers only, no nested OWNERS). This grants triage-equivalent access (auto review dispatch + /fs-review, /fs-triage slash commands) without granting write/merge/approve rights. Maintainers should decide the final roster; this proposal establishes the plumbing and nominates the strongest evidenced case.
Validation criteria
Within 2 weeks of merging the OWNERS file: (1) the next PR guyoron1 (and any other newly-added reviewer) opens against fullsend-ai/agents receives an automated fullsend review-agent comment within the normal dispatch SLA, instead of remaining unreviewed; (2) no abuse or degraded review quality is observed from the newly-authorized accounts (spot-check their triggered review runs); (3) the count of guyoron1's/Benkapner's/amastbau's open PRs older than 14 days with zero review-agent comment drops to zero going forward. If added reviewers trigger low-quality or abusive dispatches, remove them from the OWNERS file — the change is a single-file, single-line-per-entry revert.
Generated by retro agent from #1246
Activity
fullsend-ai-triage commentedon Sep 28, 2026
🤖 Finished Triage · ✅ Success · Started 8:29 AM UTC · Completed 8:33 AM UTC
Commit:
a526fa3· View workflow run →Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.41
fullsend-ai-triage commentedon Sep 28, 2026
Independently verified: fullsend-ai/agents currently has no repo-root
OWNERSfile and noauthorizationblock in.fullsend/config.yaml. Theowners_fileauthorization provider described in the proposal is real and matches fullsend-ai/fullsend's documented contract (ADR 0054 and the authorization v1 normative doc) — areviewers:entry grants at-least-triage role, and OWNERS is read from the base/default branch, so a PR cannot self-elevate its own author. PR #1246 is confirmed closed unmerged as of today.The change itself (new OWNERS file + one config.yaml block) is small and self-contained, not a bundle of unrelated concerns, and doesn't touch workflow files. The one open question — whether to onboard just guyoron1 or also Benkapner/amastbau — is explicitly left to maintainer judgment by the proposal itself; that's a reasonable place for human review to weigh in during the resulting PR rather than a gap that blocks starting the work.
No open PR/issue elsewhere addresses this, and the upstream fullsend issues cited (#4374, #2967, #5154, #6802, #2552) track the general platform-wide external-contributor gate rather than this repo's local opt-in, so this isn't a duplicate.
Proposed test coverage for the change is included in the triage summary.
Labels: Matches this repo's convention of tagging retro-agent-originated proposals with retro-agent and feature, plus security since the change grants elevated automated-dispatch access to specific external accounts.
Next steps:
/fs-code— agent creates a PR to implement this issue/fs-code <your instruction>— agent implements with your specific guidance