Sync GH: push commits+tags, close stale issues, migrate open GitLab issues to GitHub (with new GH ids tracked alongside GL ids in trajectory DB)
Why
GitHub account just got unblocked (false-positive suspension cleared by Support). Recent doctrine changes:
originswapped from GitLab → GitHub (this just happened, local git config updated)- GitLab now the secondary commit-mirror
- All future MCP issues should mirror to BOTH GH and GL
- All open issues currently live only on GitLab — need to migrate to GitHub as primary source of truth
Scope (4 work items)
1. Push local commits + tags to GitHub
Local git tree has commits beyond what's on GitHub. Push the dev branch + all stable tags (v0.1.0 through v0.6.0):
git push origin dev
git push origin --tags # but ONLY stable tags — all rc tags were deleted earlierVerify: git ls-remote origin shows dev HEAD + every stable tag.
2. Close stale GitHub issues
GitHub issues that pre-date the GitLab-canonical period. Audit gh issue list -R trustmybot/plugin --state open and close anything that's:
- Already closed/resolved on GitLab side
- Superseded by newer GitLab issues
- Stale (no activity in 3+ months)
Reference the GitLab equivalent in the close comment where applicable.
3. Migrate open GitLab issues to GitHub
For every open issue on GitLab:
- Create a new GitHub issue with the same title + description
- The NEW GH id ≠ the GL id (let GitHub auto-assign)
- Cross-link: GL issue body gets "Migrated to gh#NNN", GH issue body gets "From gl!MMM"
- Local trajectory DB rows updated to track BOTH ids (depends on schema work below)
- Do NOT close the GL issues — let
gitlabremote remain the commit mirror; issues just become read-only references after migration
4. Extend trajectory DB schema for tri-source tracking
Current: issues table has one remote_iid INTEGER, remote_kind TEXT CHECK(remote_kind IN ('github','gitlab')) — single remote per issue.
Needed: track BOTH gh_iid and gl_iid per issue (and any future provider). Two design options:
Option A (minimal): add columns
ALTER TABLE issues ADD COLUMN gh_iid INTEGER;
ALTER TABLE issues ADD COLUMN gl_iid INTEGER;
-- Backfill: existing rows where remote_kind='github' → gh_iid = remote_iid; remote_kind='gitlab' → gl_iid = remote_iid
-- Future: keep remote_iid/remote_kind for back-compat (deprecate post-v0.9), but writes go to gh_iid/gl_iidOption B (extensible): junction table
CREATE TABLE issue_remote_links (
issue_id INTEGER NOT NULL REFERENCES issues(id) ON DELETE CASCADE,
kind TEXT NOT NULL CHECK(kind IN ('github','gitlab')),
iid INTEGER NOT NULL,
url TEXT,
created_at TEXT NOT NULL,
PRIMARY KEY (issue_id, kind)
);
-- Backfill: for each issue with remote_iid, INSERT a junction row
-- Drop remote_iid/remote_kind from issues table after migrationRecommend Option A for v0.7.1 (smaller surface; back-compat preserved). Reconsider for Option B in v1.0 when adding a 3rd provider (e.g., Linear, JIRA).
MCP tool changes (per Option A)
issue_create: whenissue_sync='auto'+ multiple remotes configured, create on EACH remote, write both ids to the rowissue_close: when closing, also close on EACH remote with non-null iidissue_list/issue_get: surface both ids in returned rowissue_sync_retry: extend to retry per-remote independently
Schema migration
- New migration
migrateV4toV5inmcp/trajectory-server/src/db.ts - Backfills
gh_iid/gl_iidfrom existingremote_iid/remote_kindrows - Pre-v5 .bak file written
- L0 install-smoke A7 extends to verify legacy v4 → v5 upgrade
Acceptance criteria
- All stable tags + dev HEAD on GitHub (push success, ls-remote confirms)
- Open GitLab issues all have GitHub equivalents (1:1 mapping, cross-linked)
- Stale GitHub issues closed with rationale
issuestable hasgh_iidandgl_iidcolumns; new issues populate both whenremote=[github,gitlab]+issue_sync=autoissue_close(id=N)closes on local + GH + GL atomically- L0-L4 green throughout migration
Out of scope
- Webhook bidirectional sync (issue created on GH directly → mirror back to local) — separate concern, deferred
- Closing GitLab issues post-migration — they stay open as historical refs
- Migrating GitLab MRs to GitHub PRs — only ISSUES migrated; MRs stay on GitLab
Filed during
Re-onboarding session 2026-05-19/20 after GH suspension lift + remote rearrangement. The current issue (Sync GH itself) will be the first test of tri-source mirroring once schema lands.