Fork with enhanced deployment tools for AI‑agent management

[dominusbelial]

Hello @MrLesk and Backlog.md maintainers,

I’ve been using Backlog.md extensively for AI‑assisted project management and really appreciate the MCP‑first design. To better support my workflows, I created a fork focused on extending the deployment MCP tools (project_deploy, project_import, agent_team_launch). The fork is now public and I’d like to share the enhancements with you and the community.

Fork repository: dominusbelial/agent‑kanban‑backlog‑md‑deployment (MIT‑licensed, all original copyright notices preserved)

Enhancements added:

Selective import filters with array support and logical OR – extended project_import to accept multiple values per filter (--only‑label label:foo,label:bar) and added an --any‑label option for OR logic.
Fully implemented agent_team_launch – the placeholder handler is now a complete implementation that loads a team spec, validates agents, spawns child processes, and returns launch status.
New CLI commands – backlog project export and backlog agent‑team list (the latter is still a placeholder).
Structured error codes and improved error handling – added error categories for programmatic use and clearer error messages with actionable details.
Validation warnings – non‑blocking warnings during import for potential issues (e.g., missing dependencies).
Performance optimizations – optimized filtering logic for large task graphs.
Tutorial documentation – created examples/deployment/TUTORIAL.md and expanded example projects.
Updated README – clearly marks the fork and describes the added features.

All changes are tested (12/12 tests pass) and TypeScript compilation is clean.

Why I’m opening this issue:

Feedback welcome – I’d be grateful for your review of the changes, especially the architectural choices in the deployment tools.
Upstream interest? – If any of these enhancements align with the project’s direction, I’d be happy to prepare focused pull requests (e.g., selective‑import array support, structured error codes).
Collaboration – I’m open to adjusting the implementation to fit better with the main project’s roadmap.

Questions for you:

Are there any contribution guidelines I should follow for submitting pull requests?
Do you have a preference on how to handle the fork’s visibility (e.g., keep it as a separate “enhanced deployment” variant, or aim to merge features upstream)?
Any other feedback or suggestions?

Thank you for building such a useful tool, and I look forward to hearing your thoughts!

Note: This issue is purely informational and a request for feedback. No immediate action is required, but I’d appreciate any guidance you can offer.

[christophjahn]

You write that the changes support your workflow better. It would probably help to understand this workflow in some detail. Only then could I determine whether this interesting for me.

Thanks.

[MrLesk]

Alex's Agent: Thanks for sharing the fork. If there are specific changes that should come upstream, the most reviewable path is a focused Backlog task or PR per workflow improvement rather than evaluating the whole fork at once.

[dominusbelial]

my workflow has changed so much in just a few months, im not using these set of tools/approach anymore, calling it off for now, i appreciate the interest.