Product thesis
Gittensory should become the Gittensor contribution operating layer: the place where miners plan and validate useful work, maintainers control and trust GitHub output, repo owners assess intake readiness, and operators measure ecosystem adoption/value.
This is the adoption roadmap for the surfaces around the deterministic base-agent foundation. Keep #82 as the beta-grade base-agent v2 foundation roadmap; use this issue as the ecosystem adoption v1 parent. Do not create another top-level roadmap unless this issue is explicitly closed as superseded.
Non-goals
Gittensory should not become:
- A generic Gittensor dashboard or explorer.
- A public reward leaderboard.
- A wallet/hotkey dashboard.
- An autonomous PR bot.
- A public score predictor.
V1 success criteria
- Miners can install, plan, preflight, and generate a useful PR packet.
- Maintainers can trust, preview, and control GitHub output before it reaches public surfaces.
- Repo owners can assess intake readiness before inviting more contributor traffic.
- Operators can measure adoption/value without exposing private scoreability or implying payout outcomes.
- The browser extension is usable in the GitHub PR review flow and has screenshot-backed review states.
Tracking model
Use this issue as the narrative source of truth. Use native sub-issues for the execution tree where GitHub supports it. Keep nesting shallow: parent roadmap -> phase epic -> implementation issues.
Use one GitHub Project named Gittensory Ecosystem Adoption v1 as the operating board for status, phase, audience, surface, priority, gate, target, source, and PR linkage. Project creation/configuration requires a GitHub token with project scope.
Project board fields
- Status: Backlog, Ready, In Progress, Blocked, Review, Done, Closed/Superseded.
- Phase: 0 Stabilize, 1 Miner, 2 Maintainer, 3 Repo Owner, 4 Analytics, 5 Distribution, 6 Advanced.
- Audience: Miner, Maintainer, Repo Owner, Operator, Contributor, All.
- Surface: MCP, Web App, GitHub App, Extension, API, Data, Docs, Raycast/PWA.
- Priority: P0, P1, P2, P3.
- Confidence: High, Medium, Low.
- Gate: Needs PR, Needs screenshots, Needs CI, Needs design, Needs auth/privacy review, Ready.
- Target: Now, Next, Later, Research.
- Source: Existing issue, New issue, Existing PR, Replacement PR.
Project board views
- Roadmap: grouped by Phase, sorted by Priority.
- Current Push: filtered to Phase 0/1/2, Status not Done.
- Maintainer Trust: Audience = Maintainer or Surface = Extension/GitHub App.
- Miner Utility: Audience = Miner or Surface = MCP.
- Blocked: Status = Blocked or Gate contains CI/screenshots/auth.
- PR Queue: items linked to open PRs.
- Advanced: Phase = 6 Advanced.
Phase epics
Phase 0: Stabilize While Shipping
Live PR cleanup and deterministic blockers:
Phase 1: Miner Command Center
Phase 2: Maintainer Trust + Browser Extension
Completed foundation to link, not reopen: #135, #140, #141, #143, #144, #147, #148.
Phase 3: Repo Owner Intake Console
Phase 4: Adoption Analytics + Launch System
Completed foundation to verify before claiming complete: #136, #137, #138, #139, #149, #153.
Phase 5: Ecosystem Distribution
Phase 6: Advanced Contribution Operating Layer
Post-v1 advanced systems after phases 0-5 are stable:
Related cross-phase dependencies:
This phase must stay advisory and human-approved. It must not become public reward prediction, wallet tooling, public leaderboards, or autonomous PR automation.
Existing adoption/control-panel issues still related
Cross-cutting gates
- UI/frontend/browser-extension PRs must include actual screenshots or recordings for changed states. Missing evidence is a rejection reason.
- Public-output work must include sanitizer criteria for forbidden wallet/hotkey, reward-estimate, trust-score, public-score-prediction, private-reviewability, private-scoreability, and farming-language leakage.
- MCP/CLI work must include JSON-output, token-redaction, local path-redaction, and source-upload behavior criteria.
- Keep CI/check state separate from reviewer/mergeability state. Green checks alone do not make a PR merge-ready.
Product thesis
Gittensory should become the Gittensor contribution operating layer: the place where miners plan and validate useful work, maintainers control and trust GitHub output, repo owners assess intake readiness, and operators measure ecosystem adoption/value.
This is the adoption roadmap for the surfaces around the deterministic base-agent foundation. Keep #82 as the beta-grade base-agent v2 foundation roadmap; use this issue as the ecosystem adoption v1 parent. Do not create another top-level roadmap unless this issue is explicitly closed as superseded.
Non-goals
Gittensory should not become:
V1 success criteria
Tracking model
Use this issue as the narrative source of truth. Use native sub-issues for the execution tree where GitHub supports it. Keep nesting shallow: parent roadmap -> phase epic -> implementation issues.
Use one GitHub Project named Gittensory Ecosystem Adoption v1 as the operating board for status, phase, audience, surface, priority, gate, target, source, and PR linkage. Project creation/configuration requires a GitHub token with project scope.
Project board fields
Project board views
Phase epics
Phase 0: Stabilize While Shipping
Live PR cleanup and deterministic blockers:
installation_repositorieswebhooks are never handled — repos added to an existing installation are silently dropped (and theinstallation"added" branch is dead code) #257 installation_repositories webhook handlingPhase 1: Miner Command Center
Phase 2: Maintainer Trust + Browser Extension
Completed foundation to link, not reopen: #135, #140, #141, #143, #144, #147, #148.
Phase 3: Repo Owner Intake Console
Phase 4: Adoption Analytics + Launch System
Completed foundation to verify before claiming complete: #136, #137, #138, #139, #149, #153.
Phase 5: Ecosystem Distribution
Phase 6: Advanced Contribution Operating Layer
Post-v1 advanced systems after phases 0-5 are stable:
Related cross-phase dependencies:
This phase must stay advisory and human-approved. It must not become public reward prediction, wallet tooling, public leaderboards, or autonomous PR automation.
Existing adoption/control-panel issues still related
Cross-cutting gates