GloriousFlywheel GitHub-First Forge Parity 2026-04-16

GloriousFlywheel GitHub-First Forge Parity 2026-04-16

Snapshot date: 2026-04-16

Purpose

Define the current forge-positioning boundary for GloriousFlywheel so the repo stops implying equal maturity across GitHub, GitLab, and Codeberg when that is not true.

GitHub owner: #211

Current Recommendation

GloriousFlywheel should be presented as:

  • GitHub-first as the primary product surface
  • GitLab-compatible as an explicit interoperability and migration surface
  • Codeberg-compatible as a downstream FOSS surface with caveats, not as the primary control plane

Why GitHub-First

GitHub is where the product has the clearest current fit:

  • ARC runner scale sets are current and actively maintained
  • the direct adoption tranche already includes GitHub workflow consumers
  • the current commercial comparison set is primarily GitHub-shaped
  • the repo’s runner labels, GitHub App flows, and ARC stack are all strongest on the GitHub side

GitLab Boundary

GitLab should remain supported, but reclassified:

  • GitLab is still important for cross-forge compatibility
  • GitLab runner and dashboard control surfaces remain part of the compatibility story
  • GitLab should not be presented as the repo’s primary product identity or default operator path

Codeberg Boundary

Codeberg matters for FOSS credibility and downstream accessibility, but its role should stay narrow for now:

  • Codeberg shared CI is resource-constrained
  • Codeberg’s own documentation recommends self-hosted agents for heavier use
  • Codeberg compatibility should be documented as a supported downstream path, not treated as the primary platform that drives runner architecture

Documentation Consequence

Primary docs should:

  • lead with GitHub ARC and GitHub Actions usage
  • clearly mark GitLab runner flows as compatibility or migration paths
  • clearly mark Codeberg guidance as downstream compatibility with caveats

Backlog Consequence

Forge parity work should be decomposed into:

  • GitHub-first product docs and migration surfaces
  • GitLab compatibility hardening where it still matters
  • Codeberg compatibility docs and examples, but only after the GitHub-first surface is coherent

Acceptance Criteria

  • no primary doc implies equal maturity across GitHub, GitLab, and Codeberg
  • the repo has one explicit support statement for each forge family
  • cross-forge docs are split into primary and compatibility surfaces

GloriousFlywheel