feat: implement ISSUE-WP-0005 connector mapping and scope alignment
Add MappingService (work_record_uuid ↔ external id), project/map CLI with outward push-status, optional TaskSpec work_record fields, boundary-sync policy, and packaging/capability framing cleanup. Mark WP-0005 finished.
This commit is contained in:
parent
6855fb2a32
commit
f88e9a28fe
16 changed files with 1300 additions and 179 deletions
|
|
@ -1,60 +1,62 @@
|
|||
---
|
||||
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.
|
||||
name: External Issue Tracker Connector
|
||||
summary: Backend-agnostic CLI/Python connector to Gitea/Forgejo (and SQLite cache)
|
||||
with work-record UUID ↔ external issue mapping. Not the fleet work origin.
|
||||
owner: issue-core
|
||||
status: draft
|
||||
domain: infotech
|
||||
tags:
|
||||
- issue-tracking
|
||||
- coordination
|
||||
- multi-platform
|
||||
- connector
|
||||
- work-record
|
||||
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.
|
||||
rationale: INTENT.md, SCOPE.md, CAPABILITY-issue-tracking.yaml, mapping design,
|
||||
boundary-sync policy, AGENT_INTEGRATION.md.
|
||||
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.
|
||||
rationale: Python package + CLI (list/create/project/map) installable via pip;
|
||||
mapping store shipped; MCP not yet available.
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
confidence: low
|
||||
confidence: medium
|
||||
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)
|
||||
- Gitea + local SQLite backends
|
||||
- CLI with JSON output; project/map commands
|
||||
- work_record_uuid optional on TaskSpec
|
||||
- credential handling via env vars (GITEA_API_TOKEN, ISSUE_CORE_API_KEY)
|
||||
broken_expectations: []
|
||||
out_of_scope_expectations: []
|
||||
out_of_scope_expectations:
|
||||
- Fleet task origin / intake promotion (work-record canon)
|
||||
- Default IssueSink for internal findings (activity-core)
|
||||
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
|
||||
- manual backend configuration (auto-detect planned)
|
||||
- no built-in issue locking beyond assignee+state
|
||||
- inward boundary sync not shipped
|
||||
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.
|
||||
intent: Project and operate on external issue trackers with a stable link to
|
||||
work-record UUIDs; never replace file-first work records as coordination substrate.
|
||||
includes:
|
||||
- unified Python API and CLI over Gitea/GitHub/GitLab issue operations
|
||||
- local caching and offline mode
|
||||
- unified Python API and CLI over Gitea/SQLite issue operations
|
||||
- work_record_issue_map store + project/map/push-status
|
||||
- local offline cache and backend sync
|
||||
- credential handling via environment variables
|
||||
excludes:
|
||||
- MCP server (planned, not yet shipped)
|
||||
- distributed locking and query DSL (roadmapped for v2.0)
|
||||
- originating workplans/tasks/intake
|
||||
- MCP server (planned)
|
||||
- multi-agent fleet board semantics on Forgejo
|
||||
assumptions: []
|
||||
use_cases: []
|
||||
research_memos: []
|
||||
|
|
@ -63,70 +65,21 @@ availability:
|
|||
target_level: A3
|
||||
current_artifacts:
|
||||
- Python package (`issue_core`)
|
||||
- '`issue` CLI'
|
||||
- '`issue` CLI (including project/map)'
|
||||
target_artifacts: []
|
||||
consumption_modes:
|
||||
- cli
|
||||
- library import
|
||||
- rest (optional `[api]` extra)
|
||||
relations:
|
||||
depends_on: []
|
||||
supports:
|
||||
- capability.procurement.vergabe-teilnahme
|
||||
supports: []
|
||||
related_to:
|
||||
- capability.activity.event-coordinate
|
||||
evidence:
|
||||
documentation:
|
||||
- INTENT.md
|
||||
- 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`
|
||||
- docs/uuid-external-id-mapping.md
|
||||
- docs/boundary-sync-and-status-mapping.md
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue