tegwick
03b9e69c31
Add supports/related_to for vergabe-teilnahme and activity-core, cite SCOPE.md, update test count to 120 (verified), and document dual-canonical relationship with CAPABILITY-issue-tracking.yaml.
132 lines
5.3 KiB
Markdown
132 lines
5.3 KiB
Markdown
---
|
|
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`
|