coulomb/issue-core
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Projects Releases Wiki Activity
18 Commits 1 Branch 0 Tags
ed14952b17cae515fba6057a3490d77b4e844bf0
Commit Graph

3 Commits

Author SHA1 Message Date
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
tegwick
35daa514e5 refactor: align with ReusableCapabilitiesArchitecture v0.1 
Refactor issue-facade to conform to the new ReusableCapabilitiesArchitecture
specification, improving discoverability and establishing consistent patterns
for capability integration.

Architecture Changes:
- Rename .feedback/ → feedback/ (visible user interface)
- Rename CAPABILITY.yaml → CAPABILITY-issue-tracking.yaml (explicit family)
- Keep .capability/ hidden (evolving implementation infrastructure)

File Updates:
- Updated all documentation references (.feedback → feedback)
- Updated .capability/feedback script paths
- Updated Makefile, README.md, CLAUDE.md, examples
- Fixed CAPABILITY.yaml → CAPABILITY-issue-tracking.yaml references

New Tools:
- Created .capability/detach script for clean capability removal
- Supports git submodule and directory-based integrations
- Generates detachment manifest for re-integration guidance

Rationale:
- feedback/ is visible: encourages user participation, shows capability identity
- .capability/ is hidden: implementation details that will evolve
- CAPABILITY-<family>.yaml: explicit family declaration, supports multiple capabilities per repo
- Underscore prefix pattern: flatter hierarchy, clear signal of integration

This aligns with the principle that capabilities are conceptual units
designed for natural language integration by devhumans and devagents,
not just technical libraries.

See ReusableCapabilitiesArchitecture.md for complete specification.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
 2025-12-17 22:22:47 +01:00
tegwick
1627fd9673 feat: implement reusable feedback capability for continuous improvement 
Add comprehensive feedback system that enables lightweight, unstructured feedback
collection from users of the issue-facade capability, establishing a continuous
improvement loop grounded in real-world usage.

Core Components:
- .feedback/ directory structure (inbound, reviewed, archived)
- Standalone CLI tool (.capability/feedback) for submission and management
- Comprehensive documentation (.feedback/README.md)
- Integration examples and usage guides

Key Features:
- Multiple submission methods (CLI, Makefile, direct file drop)
- No structure imposement - accepts any text/markdown format
- Automatic metadata capture (timestamp, git context, version)
- Maintainer workflow (list, review, archive, create issues)
- Colored terminal output for better UX
- Future-ready for API endpoint evolution

Integration:
- Updated CAPABILITY.yaml with feedback section
- Enhanced CLAUDE.md with comprehensive integration guide
- Added Makefile commands (feedback, feedback-list, feedback-stats, etc.)
- Created detailed usage examples (examples/feedback-example.md)

Design Philosophy:
- Capability-agnostic pattern (reusable across all markitect capabilities)
- Decentralized (each capability owns its feedback)
- Flexible (no required formats or fields)
- Durable (plain markdown files, git-tracked)
- Actionable (feedback lives where maintainers work)
- Scalable (works for 1 user or 1000 users)

Feedback Submission Examples:
  ./.capability/feedback submit "Your feedback"
  make feedback MSG="Your feedback"
  echo "Feedback" > .feedback/inbound/$(date +%Y%m%d)-feedback.md

Maintainer Workflow:
  make feedback-list                    # List pending
  make feedback-stats                   # Show statistics
  make feedback-review-issue FILE=xxx   # Review and create issue

This establishes a robust continuous improvement loop:
User Experience → Feedback → Review → Action → Improved Capability

The pattern is designed to be copied to any capability in the markitect
project, providing consistent feedback collection across all capabilities.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
 2025-12-17 21:09:36 +01:00