issue-core/registry/capabilities/capability.infotech.issue-tracking.md

id	name	summary	owner	status	domain	tags	maturity	external_evidence	discovery	availability	relations	evidence	consumer_guidance	promotion_history
capability.infotech.issue-tracking	Universal Issue Tracking Coordination	Unified Python/CLI interface for issue tracking across Gitea, GitHub, and GitLab, preventing direct platform API usage and credential sprawl for coordinating agents.	issue-core	draft	infotech	issue-tracking coordination multi-platform	discovery availability current target confidence rationale D4 D5 high 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. current target confidence rationale A2 A3 high 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 reliability level confidence basis satisfied_expectations broken_expectations out_of_scope_expectations C2 low scope_vs_intent_and_consumer_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) level confidence basis known_reliability_risks R1 low consumer_quality_signals 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	intent includes excludes assumptions use_cases research_memos 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. unified Python API and CLI over Gitea/GitHub/GitLab issue operations local caching and offline mode credential handling via environment variables MCP server (planned, not yet shipped) distributed locking and query DSL (roadmapped for v2.0)	current_level target_level current_artifacts target_artifacts consumption_modes A2 A3 Python package (`issue_core`) `issue` CLI cli library import	depends_on supports related_to capability.procurement.vergabe-teilnahme capability.activity.event-coordinate	documentation tests consumer_feedback bug_reports incidents SCOPE.md CAPABILITY-issue-tracking.yaml AGENT_INTEGRATION.md ROADMAP.md tests/ (120 tests collected 2026-07-07; 61% coverage per CAPABILITY-issue-tracking.yaml)	recommended_for not_recommended_for known_limitations agents coordinating via Gitea/GitHub/GitLab issues who would otherwise call platform APIs directly needs requiring MCP server integration (not shipped yet) 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

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

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