What
A heads-up for anyone following or building on SchemaBot: we intend to keep
SchemaBot's core code-host-agnostic.
SchemaBot is tightly integrated with GitHub today (PR comments, Check Runs,
branch protection, reviews/CODEOWNERS), but its core isn't fundamentally
GitHub-specific: discovering declarative schema, diffing against live databases,
linting unsafe changes, planning, coordinating applies, tracking progress, and
reconciling long-running work are all host-neutral. GitHub is the review and
merge-gating shell around that core.
We're posting this for transparency: this is a direction we've decided on,
not an open question. There's no rewrite planned and no near-term change — the
point is to set expectations now.
What this means in practice
- The core (CLI, HTTP API, planning, engines, storage, reconciliation) stays
independent of any specific code host. The CLI and API already work without a
GitHub App.
- When GitHub integration code is touched, GitHub behavior gets isolated behind
a capability boundary rather than pushing new GitHub assumptions into core
types. The useful abstraction is a set of code-host capabilities, each of
which could have a provider adapter:
- repository content access (schema config + SQL files at an immutable ref)
- change/event ingestion
- human command surface (PR comments today; CLI is the universal fallback)
- merge gate / status publication (Check Runs today)
- reviews and approval state
- actor/team identity and authorization
The hard part
Merge gating and the human workflow — the tier-0 safety path. Any future
alternative must preserve today's safety properties: a required gate on every
change, missing/uncertain status fails closed, status bound to the current
immutable head, and stale status can't satisfy a newer commit.
Scope
- No rewrite for a hypothetical GitHub replacement.
- No new provider adapters in the near term.
- GitHub remains a first-class, fully supported integration.
What
A heads-up for anyone following or building on SchemaBot: we intend to keep
SchemaBot's core code-host-agnostic.
SchemaBot is tightly integrated with GitHub today (PR comments, Check Runs,
branch protection, reviews/CODEOWNERS), but its core isn't fundamentally
GitHub-specific: discovering declarative schema, diffing against live databases,
linting unsafe changes, planning, coordinating applies, tracking progress, and
reconciling long-running work are all host-neutral. GitHub is the review and
merge-gating shell around that core.
We're posting this for transparency: this is a direction we've decided on,
not an open question. There's no rewrite planned and no near-term change — the
point is to set expectations now.
What this means in practice
independent of any specific code host. The CLI and API already work without a
GitHub App.
a capability boundary rather than pushing new GitHub assumptions into core
types. The useful abstraction is a set of code-host capabilities, each of
which could have a provider adapter:
The hard part
Merge gating and the human workflow — the tier-0 safety path. Any future
alternative must preserve today's safety properties: a required gate on every
change, missing/uncertain status fails closed, status bound to the current
immutable head, and stale status can't satisfy a newer commit.
Scope