Skip to content

feat(agent): auto-match PRs to open GitHub Projects v2 (suggest-mode) #3184

Description

@JSONbored

Parent epic: #3180

Goal

Extend #3183's matcher to also match against open GitHub Projects (v2, GraphQL-only), still suggest-mode only.

Requirements

  • Requires a new GitHub App organization permission: Organization permissions → Projects: Read & write (organization_projects: write). This is an org-level scope distinct from any repo permission, and existing installations need to accept the updated permission set — coordinate the App-manifest update across all three JSONbored gate repos (gittensory, metagraphed, awesome-claude) before shipping this issue live.
  • List projects via GraphQL organization(login){ projectsV2 { nodes { id title } } } (or repo-scoped repository(owner:,name:){ projectsV2 }).
  • Resolve field/option IDs via the project's fields query before any write (needed only once auto-apply lands in the follow-up promotion issue).
  • Add GitHubProjectsAdapter implementing the ProjectTrackerAdapter interface introduced by feat(agent): auto-match PRs to open GitHub Milestones (suggest-mode) #3183.
  • Same matching machinery (tokenize/termOverlap) against project titles, same suggest-mode-only bot comment output.
  • Known unconfirmed gap to verify during implementation: community reports suggest GitHub Apps acting as Bot cannot read items in private Projects v2 even with correct permissions granted (github.com/orgs/community/discussions/148529) — confirm against a real private project during implementation and document the finding either way.

Deliverables

  • App manifest permission update (coordinated with maintainer across 3 repos).
  • GitHubProjectsAdapter.
  • Matching + suggest-mode comment for Projects v2.
  • Tests covering field-ID resolution failure, private-project-read gap (if confirmed), no-match case.

Expected outcome

Repos that opt in get suggestion comments for both Milestones and Projects v2, still fully non-destructive.

References

Correction (during implementation)

Researched during implementation, not just the community-reported gap above: GitHub Apps cannot access user-owned Projects v2 at all, by design — the "Organization permissions → Projects" scope only applies to an installation on an Organization account. All three JSONbored gate repos (gittensory, metagraphed, awesome-claude) sit under a personal User account, so:

  • The organization-permission grant already added to the App is inert for these three repos specifically (harmless to leave in place — it's simply unused here — and it WILL work correctly for any other self-hoster who installs gittensory-orb on a GitHub Organization).
  • There is no substitute App permission for a user-owned board; only a personal-access-token or user-to-server OAuth token (acting as the user, not the App installation) can reach one, which is a materially different feature (secret storage, consent flow) intentionally out of scope here.
  • GitHubProjectsAdapter.listOpenProjects therefore queries repositoryOwner(login){ __typename ... on Organization { projectsV2 { ... } } } in one call: a User-owned repo's owner resolves to __typename: "User", the inline fragment contributes nothing, and the result is an empty list — the same, safe "no open projects" outcome as an Organization with none, never a thrown error. This means the feature is fully real and useful for org-owned self-hosters, and a documented, graceful no-op for JSONbored's own (user-owned) repos.
  • The "Bot can't read private Projects v2" gap from the Requirements above was not independently re-verified (no real private Projects v2 board was available to test against) — it's called out in code comments as a known, unconfirmed community report, and degrades the same safe way (empty list) regardless.

Sources: docs.github.com/en/rest/authentication/permissions-required-for-github-apps (the User-permissions category has no Projects entry), github.com/orgs/community/discussions/46681, /64849, /148529.

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions