Skip to content

roadmap: Gittensory ecosystem adoption v1 #127

@JSONbored

Description

@JSONbored

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.

Metadata

Metadata

Assignees

Labels

agentAgent planning, action ranking, or orchestration.developer-experienceInstall, diagnostics, docs-adjacent developer experience.high-impactHigh-value issue for Gittensory's base-agent direction.maintainer-valueImproves maintainer review, triage, or trust workflows.miner-valueImproves the miner/contributor decision workflow.

Projects

Status
Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions