---
id: capability.infotech.issue-tracking
name: Universal Issue Tracking Coordination
summary: Unified Python/CLI interface for issue tracking across Gitea, GitHub, and GitLab, preventing
  direct platform API usage and credential sprawl for coordinating agents.
owner: issue-core
status: draft
domain: infotech
tags:
- issue-tracking
- coordination
- multi-platform
maturity:
  discovery:
    current: D4
    target: D5
    confidence: high
    rationale: SCOPE.md, CAPABILITY-issue-tracking.yaml (agent-integration deep spec), AGENT_INTEGRATION.md,
      ROADMAP.md, and .capability/ feedback cover usage rules, API surface, and credential handling. This
      registry entry is the federation-facing normalization of that material — the YAML manifest remains
      the detailed agent-integration companion, not superseded.
  availability:
    current: A2
    target: A3
    confidence: high
    rationale: Both a Python API (`from issue_core.backends.gitea import GiteaBackend`) and a CLI (`issue
      list/create/show/edit/close/comment`, JSON output) are installable via pip; MCP server is planned
      but not yet available.
external_evidence:
  completeness:
    level: C2
    confidence: low
    basis: scope_vs_intent_and_consumer_expectations
    satisfied_expectations:
    - Gitea backend implemented; GitHub/GitLab described in scope
    - CLI with JSON output and offline/local caching
    - credential handling via env vars per credential-routing conventions (GITEA_API_TOKEN, never in code/logs)
    broken_expectations: []
    out_of_scope_expectations: []
  reliability:
    level: R1
    confidence: low
    basis: consumer_quality_signals
    known_reliability_risks:
    - manual backend configuration required in v1.0 (auto-detect planned for v1.1)
    - no built-in issue locking beyond assignee+comment convention
    - MCP server not yet available
discovery:
  intent: Give coordinating agents a single, credential-safe interface for issue tracking across Gitea/GitHub/GitLab
    instead of direct platform API calls, CLI wrapping, or custom scripts.
  includes:
  - unified Python API and CLI over Gitea/GitHub/GitLab issue operations
  - local caching and offline mode
  - credential handling via environment variables
  excludes:
  - MCP server (planned, not yet shipped)
  - distributed locking and query DSL (roadmapped for v2.0)
  assumptions: []
  use_cases: []
  research_memos: []
availability:
  current_level: A2
  target_level: A3
  current_artifacts:
  - Python package (`issue_core`)
  - '`issue` CLI'
  target_artifacts: []
  consumption_modes:
  - cli
  - library import
relations:
  depends_on: []
  supports:
  - capability.procurement.vergabe-teilnahme
  related_to:
  - capability.activity.event-coordinate
evidence:
  documentation:
  - SCOPE.md
  - CAPABILITY-issue-tracking.yaml
  - AGENT_INTEGRATION.md
  - ROADMAP.md
  tests:
  - tests/ (120 tests collected 2026-07-07; 61% coverage per CAPABILITY-issue-tracking.yaml)
  consumer_feedback: []
  bug_reports: []
  incidents: []
consumer_guidance:
  recommended_for:
  - agents coordinating via Gitea/GitHub/GitLab issues who would otherwise call platform APIs directly
  not_recommended_for:
  - needs requiring MCP server integration (not shipped yet)
  known_limitations:
  - manual backend configuration in v1.0; no built-in issue locking beyond assignee convention
  - CAPABILITY-issue-tracking.yaml and registry/capabilities/ coexist — update both when agent rules change
promotion_history: []
---

# Universal Issue Tracking Coordination

## Overview

`issue-core` is a universal interface for issue-tracking coordination across Gitea, GitHub, and GitLab, giving agents a unified Python API and CLI instead of direct platform API calls. This registry entry is the federation-facing form of the repo's `CAPABILITY-issue-tracking.yaml` manifest (120 tests, 61% coverage, documented usage rules and credential handling). The YAML file remains the detailed agent-integration companion.

## Assessment notes

### Discovery

Repo already carries its own detailed capability manifest (CAPABILITY-issue-tracking.yaml) plus AGENT_INTEGRATION.md, ROADMAP.md, and a .capability/ feedback-submission mechanism; usage rules, API surface, and credential handling are all explicitly documented. This entry migrates that existing description into the standard registry location rather than drafting fresh.

### Availability

Both a Python API (`from issue_core.backends.gitea import GiteaBackend`) and a CLI (`issue list/create/show/edit/close/comment`, JSON output) are installable via pip; MCP server is planned but not yet available.

### Completeness

First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.

### Reliability

No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.

## Promotion checklist

- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [x] Relations reference valid capability IDs (vergabe-teilnahme, activity-core)
- [x] Index entry added in `registry/indexes/capabilities.yaml`