Plan: GitHub Projects (board) compatibility#37
Merged
Conversation
specsync is issue-only: lifecycle is a stage: label, no assignee handling, no ProjectV2/board awareness (github.go). For teams whose backlog is a GitHub Projects board, synced issues never appear as active work (verified: ExoKit#16 onBoard=false/status=null/assignees=[]). Plan an opt-in target ProjectV2: resolve number->node id, discover the Status field/options, detect membership via issue.projectItems, ensure the issue is on the board, map stage->Status, and assign the viewer — grounded in the ExopenGitHub backlog MCP (metaverse/backlog) mechanisms, run through `gh api graphql`, without clobbering human curation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Project a synced change onto a GitHub ProjectV2 board when -project owner/number (or $SPECSYNC_PROJECT) is set; unset keeps behavior unchanged with zero board calls. The new type-asserted BoardProjector capability drives everything through `gh api graphql` via the provider's injected runner: - resolve project node id (org first, user fallback), cached per run - discover the Status single-select field + option ids from the schema (never hard-coded), mapping stage->status name with a fail-loud unknown - detect board membership by the issue's projectItems (uniform for fresh and existing issues) - ensure on board (addProjectV2ItemById), set Status (updateProjectV2ItemFieldValue) only when unset or specsync-managed, assign the viewer/"me" or a configured login only when unassigned - classify insufficient-scope failures into a clear `project` scope message Wired into sync and pull after the issue upsert; -dry-run previews the board plan and issues no GraphQL. Faked-gh unit tests cover resolution, membership, idempotency, non-clobber, viewer resolution, dry-run, and the unconfigured no-op. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Spec-only PR (proposal + spec + tasks; no code yet) planning GitHub Projects (board) compatibility for specsync.
Problem
specsync projects onto GitHub Issues only. Lifecycle is emitted as a
stage:label; there's no assignee handling and no ProjectV2/board awareness anywhere (github.go). For a team whose backlog is a GitHub Projects board, synced issues never show up as active work. Verified against ExopenGitHub Project #6: specsync-createdExoKit#16wasonBoard: false,status: null,assignees: []— only astage:activelabel.Plan (opt-in, backward-compatible)
-project owner/number(org/user ProjectV2) onsync/pull; unset ⇒ no board behavior (unchanged).issue { projectItems { nodes { project { id } } } }— uniform for freshly-created (empty) and existing issues.addProjectV2ItemById), map stage → Status (updateProjectV2ItemFieldValuew/singleSelectOptionId), assign the viewer/"me"(login→user id).projectscope (echoes the publish-scope fix instable-projection-ref-key/Epic & sub-issue projection #2) — reported as a clear error.gh api graphql(no Octokit dep).Prior art
Grounded in the ExopenGitHub
backlogMCP (metaverse/backlog/src), which drives this same board: node-id addressing, startup schema discovery → name↔id maps,repo#number/node-id membership index, batched aliased field mutations, two-id model (project-item id vs issue content id), andgit config user.email-anchored viewer identity.Implementation to follow in a separate PR.
🤖 Generated with Claude Code