Files
issue-core/README.md
tegwick b605d970e3 feat: rename to issue-core and add task ingestion endpoint
Renames the package, distribution, CLI alias, Makefile targets, and
working directory from issue-facade to issue-core, signalling its
role as the authoritative task lifecycle manager for the Coulomb org
(peer to activity-core, rules-core, project-core).

Adds POST /issues/ ingestion endpoint for activity-core's IssueSink,
under a new optional [api] extra. The endpoint is served by `issue
serve`, authenticates via the ISSUE_CORE_API_KEY env var (Bearer or
X-API-Key header), and routes the TaskSpec payload to the configured
default backend with full traceability metadata embedded in
sync_metadata.

- T01: Python package issue_tracker -> issue_core, dir rename
- T02: registered in state hub under custodian domain
- T03: INTENT.md (what it is, what it isn't, how it fits)
- T04: SCOPE.md (in/out-of-scope, integration boundaries)
- T05: POST /issues/ via FastAPI + Uvicorn, 9 unit tests
- T06: docs/nats-task-ingestion.md design stub

Closes ISSC-WP-0001.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-17 05:16:27 +02:00

415 lines
13 KiB
Markdown

# Issue Core - Agent Coordination via Issue Tracking
**A unified interface for autonomous coding agents to coordinate project implementation through issue tracking systems.**
## Purpose
The **Issue Core** provides a standardized abstraction layer for coding agents to interact with issue tracking backends (Gitea, GitHub, GitLab, local SQLite). Instead of each agent implementing platform-specific API integrations, they use one consistent interface that works across all backends.
### Why Issue Tracking for Agent Coordination?
Issue tracking provides natural coordination primitives for multi-agent software development:
- **Task Distribution**: Issues represent discrete work units agents can claim and execute
- **Progress Tracking**: States (open → in_progress → closed) track work across the team
- **Communication**: Comments enable agent-to-agent and agent-to-human communication
- **Visibility**: Labels, assignees, and milestones provide real-time project status
- **Human Integration**: Humans can seamlessly participate in agent-driven development
## Current Status
**Production-ready core with manual setup** (v1.0)
**Fully Implemented:**
- Complete CRUD operations (issues, labels, users, milestones, comments)
- Gitea backend (production-ready with full API integration)
- Local SQLite backend (offline work with sync capability)
- CLI with JSON output for machine parsing
- Python API for programmatic access
- Comprehensive filtering and search
- Basic synchronization between backends
⚠️ **Current Limitations:**
- Manual backend configuration required (one-time setup per project)
- No auto-detection from git remotes (coming in v1.1)
- Basic conflict resolution (manual intervention for complex cases)
- Hardcoded user context (agents need external identity management)
## Quick Start
### Installation
```bash
cd capabilities/issue-core
pip install -e . # CLI only
pip install -e ".[api]" # CLI + REST ingestion server
```
### REST Ingestion Server
issue-core exposes `POST /issues/` for upstream emitters (primarily
activity-core's `IssueSink`). Launch with:
```bash
export ISSUE_CORE_API_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(32))')"
issue serve --host 0.0.0.0 --port 8765
```
Clients authenticate with `Authorization: Bearer <key>` or `X-API-Key: <key>`.
See `SCOPE.md` "TaskSpec payload" for the request schema, or visit
`http://<host>:<port>/docs` once the server is running for live OpenAPI docs.
### Configuration (One-Time Setup)
**For Gitea-backed projects:**
```bash
# Set your Gitea token
export GITEA_API_TOKEN="your-token-here"
# Configure backend
issue backend add myproject gitea
# Prompts for: URL, owner, repo (reads token from environment)
# Set as default
issue backend set-default myproject
# Verify
issue backend test myproject
```
**For local/offline work:**
```bash
issue backend add local-work local
# Prompts for: database path (.issue-core/issues.db)
issue backend set-default local-work
```
### Basic Usage
```bash
# List issues (JSON output for agents)
issue list --format=json
# Create issue
issue create "Implement user authentication" \
--label=feature --label=priority:high
# Update state
issue edit 42 --state=in_progress --assignee=agent-coder
# Add comment
issue comment 42 "Implementation complete, tests passing"
# Close issue
issue close 42 --comment="Ready for review"
```
## Agent Integration
**For autonomous coding agents**, see **[AGENT_INTEGRATION.md](AGENT_INTEGRATION.md)** for:
- Programmatic Python API usage
- Multi-agent coordination patterns
- Agent workflow examples
- Label-based role assignment
- State machine workflows
- Comment-based communication protocols
- Workarounds for current limitations
- Performance optimization tips
Quick example:
```python
from issue_core.backends.gitea import GiteaBackend
from issue_core.core.interfaces import IssueFilter
# Initialize
backend = GiteaBackend()
backend.connect(config)
# Query issues for agent
issues = backend.list_issues(IssueFilter(
state='open',
labels=['bug', 'priority:critical'],
assignee='agent-coder'
))
# Process each issue
for issue in issues:
# Agent implements fix
result = agent.fix_bug(issue)
# Report back
issue.state = IssueState.CLOSED
backend.update_issue(issue)
```
## Architecture
### Facade Pattern with Plugin Backends
```
┌─────────────────────────────────────┐
│ CLI Layer (Click) │
│ issue list | create | edit │
└──────────────┬──────────────────────┘
┌──────────────▼──────────────────────┐
│ Core Domain Models │
│ (Issue, Label, User, etc.) │
└──────────────┬──────────────────────┘
┌──────────────▼──────────────────────┐
│ Backend Interface (ABC) │
│ IssueBackend, SyncableBackend │
└──────────────┬──────────────────────┘
┌───────┴────────┐
│ │
┌──────▼─────┐ ┌──────▼──────┐
│ Local │ │ Gitea │
│ (SQLite) │ │ (REST API) │
└────────────┘ └─────────────┘
```
**Key Design Principles:**
- Backend-agnostic core models
- Plugin architecture for easy backend addition
- Type-safe interfaces with comprehensive testing
- Sync support for offline/online workflows
### Supported Backends
| Backend | Status | Features |
|---------|--------|----------|
| **Gitea** | ✅ Production | Full API, rate limiting, state mapping |
| **Local SQLite** | ✅ Production | Offline work, fast queries, sync support |
| **GitHub** | 🚧 Planned (v1.1) | Full API integration |
| **GitLab** | 🚧 Planned (v1.2) | Full API integration |
## Use Cases
### 1. Multi-Agent Project Implementation
Multiple specialized agents coordinate via issues:
```bash
# Agent 1 (Coder): Claims and implements features
issue list --label=needs-implementation --format=json | \
jq -r '.[0].number' | \
xargs -I {} issue edit {} --assignee=agent-coder --state=in_progress
# Agent 2 (Reviewer): Reviews completed work
issue list --label=needs-review --format=json | \
jq -r '.[0].number' | \
xargs -I {} issue comment {} "Code review: Approved"
# Agent 3 (Tester): Runs tests
issue list --label=reviewed --format=json | \
jq -r '.[0].number' | \
xargs -I {} issue comment {} "Tests passing: 100%"
```
### 2. Agent-Human Collaboration
Agents propose implementations, humans approve:
```python
# Agent creates subtasks from human requirements
feature = backend.get_issue_by_number(100)
for subtask in agent.break_down_feature(feature):
backend.create_issue(subtask)
# Human reviews and approves via comments
# Agent monitors and proceeds with implementation
```
### 3. Offline Development with Sync
Work offline with local backend, sync when online:
```bash
# Setup local backup
issue backend add backup local
issue sync pull gitea-production backup
# Work offline
issue backend set-default backup
issue create "Offline implementation" --label=offline
# Sync back
issue sync push backup gitea-production
```
## CLI Commands Reference
### Issue Operations
```bash
issue list [--state STATE] [--label LABEL] [--assignee USER] [--format FORMAT]
issue show ISSUE_NUMBER [--comments] [--format FORMAT]
issue create TITLE [--description DESC] [--label LABEL] [--assignee USER]
issue edit ISSUE_NUMBER [--title TITLE] [--state STATE] [--add-label LABEL]
issue close ISSUE_NUMBER [--comment COMMENT]
issue reopen ISSUE_NUMBER [--comment COMMENT]
issue comment ISSUE_NUMBER BODY
```
### Backend Management
```bash
issue backend list
issue backend add NAME TYPE
issue backend remove NAME
issue backend test NAME
issue backend set-default NAME
```
### Synchronization
```bash
issue sync status
issue sync pull SOURCE TARGET [--dry-run] [--force]
issue sync push SOURCE TARGET
issue sync bidirectional BACKEND1 BACKEND2
```
## Development
### Testing
```bash
# Install with dev dependencies
make install-dev
# Run all tests (109 tests, 61% coverage)
make test
# Run with coverage report
make test-cov
# Run only unit tests
make test-unit
```
### Code Quality
```bash
# Run linter
make issue-core-lint
# Format code
black issue_core/ tests/
# Type check
mypy issue_core/
```
### Project Structure
```
issue-core/
├── issue_core/
│ ├── core/ # Domain models and interfaces
│ │ ├── models.py # Issue, Label, User, etc.
│ │ └── interfaces.py # IssueBackend, SyncableBackend
│ ├── backends/
│ │ ├── gitea/ # Gitea backend implementation
│ │ └── local/ # SQLite backend implementation
│ └── cli/ # Click-based CLI
│ ├── commands.py # Issue operations
│ ├── backend_commands.py
│ └── sync_commands.py
├── tests/ # 109 tests, comprehensive coverage
├── examples/ # Agent integration examples
├── AGENT_INTEGRATION.md # Agent coordination guide
├── CLAUDE.md # Development guide for Claude Code
└── ROADMAP.md # Future enhancements
```
## Documentation
- **[AGENT_INTEGRATION.md](AGENT_INTEGRATION.md)** - Comprehensive guide for autonomous agents
- Programmatic API usage
- Multi-agent coordination patterns
- Workflow examples and strategies
- Performance optimization
- Current workarounds
- **[CLAUDE.md](CLAUDE.md)** - Development guide for working on this codebase
- Architecture deep-dive
- Testing strategy
- Adding new backends
- Common development tasks
- **[ROADMAP.md](ROADMAP.md)** - Planned features and implementation timeline
## Roadmap
### v1.1 - Auto-Configuration (Next)
- Automatic git remote detection
- Environment-variable-only setup
- Per-repository configuration files
- `issue config detect` command
### v1.2 - Agent Features
- Agent identity management
- Issue claiming/locking API
- Webhook support for reactive agents
- Structured metadata for agent state
### v2.0 - Advanced Coordination
- Issue dependency tracking
- Query DSL for complex filters
- Activity streams and event logs
- Distributed locking for concurrent operations
## Comparison with Platform CLIs
| Feature | Issue Core | gh (GitHub) | glab (GitLab) |
|---------|--------------|-------------|---------------|
| Multi-backend support | ✅ Yes | ❌ GitHub only | ❌ GitLab only |
| Offline capability | ✅ Local SQLite | ❌ No | ❌ No |
| Agent-friendly API | ✅ Python + JSON | ⚠️ CLI only | ⚠️ CLI only |
| Consistent interface | ✅ Same across all | ❌ Platform-specific | ❌ Platform-specific |
| Backend sync | ✅ Yes | ❌ No | ❌ No |
| Auto-configuration | 🚧 Coming v1.1 | ✅ Yes | ✅ Yes |
## Contributing
The Issue Core is designed to be extensible:
**To add a new backend:**
1. Implement the `IssueBackend` interface (see `core/interfaces.py`)
2. Handle platform-specific API details in your backend
3. Map platform models to/from core domain models
4. Add comprehensive tests
5. Register in `BackendFactory`
**Backend implementation checklist:**
- [ ] All CRUD operations (issues, labels, users, milestones, comments)
- [ ] State mapping to/from platform-specific states
- [ ] Error handling and rate limiting
- [ ] Sync support (if applicable)
- [ ] Integration tests with mock API
- [ ] Documentation
See existing backends (Gitea, Local) as reference implementations.
## Why "Facade"?
The **Facade Pattern** describes this tool's purpose:
> *"Provide a unified interface to a set of interfaces in a subsystem."*
> — Gang of Four, Design Patterns
Instead of coding agents learning different APIs for GitHub (`gh`), GitLab (`glab`), Gitea, JIRA, etc., they use one consistent interface. The facade doesn't replace issue trackers—it makes them easier to use uniformly.
## License
MIT License - See LICENSE file
## Part of MarkiTect
This capability is part of the [MarkiTect Project](https://github.com/markitect), a collection of tools for agent-driven software development.