You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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).
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.
Parent epic: #3180
Goal
Extend #3183's matcher to also match against open GitHub Projects (v2, GraphQL-only), still suggest-mode only.
Requirements
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.organization(login){ projectsV2 { nodes { id title } } }(or repo-scopedrepository(owner:,name:){ projectsV2 }).fieldsquery before any write (needed only once auto-apply lands in the follow-up promotion issue).GitHubProjectsAdapterimplementing theProjectTrackerAdapterinterface introduced by feat(agent): auto-match PRs to open GitHub Milestones (suggest-mode) #3183.Botcannot 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
GitHubProjectsAdapter.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:
GitHubProjectsAdapter.listOpenProjectstherefore queriesrepositoryOwner(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.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.