tegwick
689f506bcd
Honest first-pass maturity vector grounded in README/docs/tests present in this repo; no invented evidence. Flagged for human review before publish. See reuse-surface history/2026-07-06-coverage-classification.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
128 lines
5 KiB
Markdown
128 lines
5 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: 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:
|
|
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: []
|
|
related_to: []
|
|
evidence:
|
|
documentation:
|
|
- CAPABILITY-issue-tracking.yaml
|
|
- AGENT_INTEGRATION.md
|
|
- ROADMAP.md
|
|
tests:
|
|
- tests/ (109 tests, 61% coverage per CAPABILITY-issue-tracking.yaml testing section)
|
|
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
|
|
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 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
|
|
|
|
- [x] ID follows `capability.<domain>.<name>` pattern
|
|
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
|
|
- [x] `external_evidence` is populated separately from `maturity`
|
|
- [ ] Relations reference valid capability IDs (none yet)
|
|
- [x] Index entry added in `registry/indexes/capabilities.yaml`
|