GitHub Issues & Projects

One App install, two trackers: repository issues, and Projects boards with real columns.

GitHub connects through the Peractor GitHub App — an admin installs it once on the account or organization (Install Peractor for GitHub). Peractor stores no long-lived tokens: the App mints short-lived, repo-scoped credentials on demand. The same install powers two separate trackers, because GitHub has two very different task models.

GitHub Issues

• Import unit: a repository. Every open issue becomes a task; closed or transferred issues leave the backlog.
• Statuses are honest: GitHub issues are open or closed, so that's the model — Open and Closed, nothing invented. The panel is a flat list, not a fake board. Labels import too, but as routing inputs, not columns.
• Sync is instant: the App's webhook delivers issue events as they happen, with the 30-second poll as backstop.
• Peractor's outbound status write opens or closes the issue; comments post as the App. Published artifacts arrive as links (GitHub has no comment-attachment API).
• An imported repository also fills in the project's repo if it doesn't have one — issue tracker and codebase usually travel together.

GitHub Projects (v2)

• Import unit: an organization-owned Project board. Every item imports, whatever its column.
• Real columns: the board's Status field becomes the task's status vocabulary, in board order, with colors. Workflow automation can move items across columns (setStatus: "<connector>:Done").
• Comments go to the item's underlying issue (draft items have none); sync is by poll.
• Requires the App to have Organization Projects: Read & write — if the grant is missing, the settings page shows a re-connect warning.

The App is also the recommended push credential: the same install lets runs push branches and open and merge PRs with per-run, per-repo tokens.