GitHub sync

Two ways to run sync

• Git data only — plain hyper-pm sync (no flags). Runs git fetch / git merge / git push for the data branch. No GitHub API, no token. Runs even when sync is off in config.
• Git + full GitHub mirror — hyper-pm sync --with-github. Pushes ticket changes to GitHub Issues, pulls inbound edits into JSONL, then ingests linked PR timeline activity when applicable. Requires auth and a config where sync is not off.

The legacy --git-data flag is a no-op (plain sync is already git-only).

Config sync field

• off — sync --with-github is rejected.
• outbound or full — both allow sync --with-github and behave the same: the CLI always runs outbound, inbound, and PR activity together. The two values remain for backward compatibility with existing config.json files.

Outbound behavior

• Issue labels include hyper-pm, ticket, plus each ticket label (GitHub’s label length limits apply).
• Ticket planning (priority, size, estimate, schedule) is embedded in a fenced JSON block after the issue body so full inbound can round-trip fields conservatively (only keys present in the fence participate — older issues without keys are not mass-cleared).

Inbound (part of --with-github)

Compares non-reserved labels and the planning JSON fence to the local projection and appends GithubInboundUpdate when something differs. When an issue’s body references a ticket id but the projection row has no githubIssueNumber yet, inbound appends GithubIssueLinked once so PR discovery can use that issue number (covers manually linked GitHub issues and older data). If the issue has several JSON fenced blocks, hyper-pm uses the one that contains hyper_pm_id (so a JSON snippet earlier in the description does not hide the real metadata fence).

After inbound, for tickets that are not done or cancelled, hyper-pm resolves linked PR numbers from Refs / Closes / Fixes / Resolves in the ticket body, from the GitHub issue timeline for githubIssueNumber, and (when needed) from a search of open PRs with linked:issue whose bodies reference that issue (Closes / Fixes / Resolves / Refs). It then loads PR timelines, appending GithubPrActivity events. Replaying kind: "opened" (only while the PR is open) sets in_progress; kind: "merged" sets done. Projection replay applies all other events first, then GithubPrActivity in time order, so PR timestamps from GitHub (often before the hyper-pm ticket was created) still update status correctly. This uses extra GitHub API calls (including search when any ticket has a linked GitHub issue).

Issue creation vs update

• Creates on GitHub only happen for tickets with a valid epic + story chain.
• Tickets without a story are skipped for creation until you attach --story.
• Tickets that already have a githubIssueNumber are still updated when unlinked (the issue body drops parent ids until you link again).

Assignees

Tickets store at most one assignee (GitHub login). Outbound sync sets that user as the issue’s assignee (additional assignees on the issue may be removed). Inbound reads the first assignee when GitHub returns several.