Context
gittensory is broadening beyond being a gittensor-subnet-only tool (upcoming rebrand to "loopover"). As part of that, experimental.gittensor is becoming an opt-in plugin instead of a core dependency, so a self-host operator who is not a gittensor miner has zero footprint from the gittensor subnet — no fetch from entrius/gittensor's registry file, no local tracking of unrelated subnet repos, no backfill spend on repos they never installed the app on.
The plugin-toggle infrastructure itself (the experimental: manifest block, src/review/gittensor-wire.ts, the refresh-registry cron gate) is landing separately and does not depend on this epic.
While implementing that, we found repositories.isRegistered is NOT narrowly "is this repo part of the gittensor subnet" — it is also checked as a general "is this repo active for gittensory" gate by many unrelated features (signal-snapshot generation, data-fidelity repair, the open-data backfill, burden forecasts, ops-alerts, selftune, maintainer-recap, RAG indexing). Proven empirically: scoping persistRegistrySnapshot's writes to gittensor-opted-in repos broke 130 tests across 10 files — including tests for fidelity repair and signal-snapshot fan-out that have nothing to do with subnet economics.
The root problem: in gittensory's original miner-only design, every repo it operated on WAS by definition a gittensor-subnet-registered repo, so isRegistered and "repo this instance operates on" were always the same set. That assumption is no longer true. There is already a separate, correctly-maintained repositories.isInstalled column (set by upsertRepositoryFromGitHub based on GitHub App installation) that is the right signal for "repo this instance operates on," independent of subnet membership.
Goal
Migrate every CORE (non-gittensor-specific) feature currently gated on isRegistered to use isInstalled instead, so:
- A self-host operator's own installed/configured repos keep full review + maintenance functionality regardless of gittensor-plugin status.
- Repos that are gittensor-subnet members but NOT installed on this instance (the original reported problem: 15 unrelated miner repos flooding the backfill queue) get zero treatment from any CORE feature.
- Once nothing else depends on
isRegistered for non-gittensor purposes, registry/sync.ts's writes can safely be scoped to gittensor-opted-in repos only (the final sub-issue), completing full isolation.
Non-goals
- Not renaming/rebranding the product itself (separate initiative).
- Not changing gittensor-subnet economics/scoring semantics (emission share, maintainer cut, label multipliers, earn-URLs, decision-packs) — these correctly stay gated on
isRegistered/the gittensor opt-in.
Landing order
#5028 (blocking prerequisite) → #5021 → #5019, #5020, #5022 (parallel) → #5023, #5024 (parallel) → #5025 (needs a product decision first) → #5026 → #5027 (final: re-scope registry/sync.ts, only safe once the above are live).
Sub-issues
Why this matters right now
This is what's actually keeping the reported "job queue pending is high, traffic is low" symptom from being durably fixed. A one-time manual DB cleanup on the self-host box stops the immediate bleeding, but without #5021 landing, any future growth in the gittensor subnet's registry (more miner repos) reproduces the exact same runaway backfill queue.
Design-principle cross-reference (added 2026-07-12)
This issue's goal — making subnet-specific code an opt-in plugin with zero footprint on core self-host, instead of a core dependency — is the same underlying principle behind the self-host/cloud architecture pattern recommended in #4877 (ORB Cloud Readiness) and #5230 (AMS Cloud Readiness): keep the core product-logic package unmodified, put anything optional/variant in a clearly separate, additive layer, never fork or entangle. Different axis (subnet-optionality vs. hosted-optionality), same discipline — worth applying consistent judgment across both.
Context
gittensory is broadening beyond being a gittensor-subnet-only tool (upcoming rebrand to "loopover"). As part of that,
experimental.gittensoris becoming an opt-in plugin instead of a core dependency, so a self-host operator who is not a gittensor miner has zero footprint from the gittensor subnet — no fetch fromentrius/gittensor's registry file, no local tracking of unrelated subnet repos, no backfill spend on repos they never installed the app on.The plugin-toggle infrastructure itself (the
experimental:manifest block,src/review/gittensor-wire.ts, therefresh-registrycron gate) is landing separately and does not depend on this epic.While implementing that, we found
repositories.isRegisteredis NOT narrowly "is this repo part of the gittensor subnet" — it is also checked as a general "is this repo active for gittensory" gate by many unrelated features (signal-snapshot generation, data-fidelity repair, the open-data backfill, burden forecasts, ops-alerts, selftune, maintainer-recap, RAG indexing). Proven empirically: scopingpersistRegistrySnapshot's writes to gittensor-opted-in repos broke 130 tests across 10 files — including tests for fidelity repair and signal-snapshot fan-out that have nothing to do with subnet economics.The root problem: in gittensory's original miner-only design, every repo it operated on WAS by definition a gittensor-subnet-registered repo, so
isRegisteredand "repo this instance operates on" were always the same set. That assumption is no longer true. There is already a separate, correctly-maintainedrepositories.isInstalledcolumn (set byupsertRepositoryFromGitHubbased on GitHub App installation) that is the right signal for "repo this instance operates on," independent of subnet membership.Goal
Migrate every CORE (non-gittensor-specific) feature currently gated on
isRegisteredto useisInstalledinstead, so:isRegisteredfor non-gittensor purposes,registry/sync.ts's writes can safely be scoped to gittensor-opted-in repos only (the final sub-issue), completing full isolation.Non-goals
isRegistered/the gittensor opt-in.Landing order
#5028 (blocking prerequisite) → #5021 → #5019, #5020, #5022 (parallel) → #5023, #5024 (parallel) → #5025 (needs a product decision first) → #5026 → #5027 (final: re-scope registry/sync.ts, only safe once the above are live).
Sub-issues
isInstalledpopulation for brokered self-hostisInstalledisInstalledbackfill-registered-reposjob family toisInstalled— the direct fix for the reported queue-growth incidentisInstalledregistry/sync.tsself-host scoping to gittensor-opted-in repos (final step)Why this matters right now
This is what's actually keeping the reported "job queue pending is high, traffic is low" symptom from being durably fixed. A one-time manual DB cleanup on the self-host box stops the immediate bleeding, but without #5021 landing, any future growth in the gittensor subnet's registry (more miner repos) reproduces the exact same runaway backfill queue.
Design-principle cross-reference (added 2026-07-12)
This issue's goal — making subnet-specific code an opt-in plugin with zero footprint on core self-host, instead of a core dependency — is the same underlying principle behind the self-host/cloud architecture pattern recommended in #4877 (ORB Cloud Readiness) and #5230 (AMS Cloud Readiness): keep the core product-logic package unmodified, put anything optional/variant in a clearly separate, additive layer, never fork or entangle. Different axis (subnet-optionality vs. hosted-optionality), same discipline — worth applying consistent judgment across both.