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 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. 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	documentation tests consumer_feedback bug_reports incidents CAPABILITY-issue-tracking.yaml AGENT_INTEGRATION.md ROADMAP.md tests/ (109 tests, 61% coverage per CAPABILITY-issue-tracking.yaml testing section)	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

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 migrates the repo's own pre-existing CAPABILITY-issue-tracking.yaml capability manifest (109 tests, 61% coverage, documented usage rules and credential handling) into the standard registry/capabilities/ location.

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 (none yet)
• Index entry added in registry/indexes/capabilities.yaml