devclaw-gitea/docs/ROADMAP.md

DevClaw — Roadmap

Configurable Roles

Currently DevClaw has two hardcoded roles: DEV and QA. Each project gets one worker slot per role. The pipeline is fixed: DEV writes code, QA reviews it.

This works for the common case but breaks down when you want:

• A design role that creates mockups before DEV starts
• A devops role that handles deployment after QA passes
• A PM role that triages and prioritizes the backlog
• Multiple DEV workers in parallel (e.g. frontend + backend)
• A project with no QA step at all

Planned: role configuration per project

Roles become a configurable list instead of a hardcoded pair. Each role defines:

• Name — e.g. design, dev, qa, devops
• Tiers — which developer tiers can be assigned (e.g. design only needs medior)
• Pipeline position — where it sits in the task lifecycle
• Worker count — how many concurrent workers (default: 1)

{
  "roles": {
    "dev": { "tiers": ["junior", "medior", "senior"], "workers": 1 },
    "qa": { "tiers": ["qa"], "workers": 1 },
    "devops": { "tiers": ["medior", "senior"], "workers": 1 }
  },
  "pipeline": ["dev", "qa", "devops"]
}

The pipeline definition replaces the hardcoded Doing → To Test → Testing → Done flow. Labels and transitions are generated from the pipeline config. Auto-chaining follows the pipeline order.

Open questions

• How do custom labels map? Generate from role names, or let users define?
• Should roles have their own instruction files (projects/prompts/<project>/<role>.md) — yes, this already works
• How to handle parallel roles (e.g. frontend + backend DEV in parallel before QA)?

---

Channel-agnostic groups

Currently DevClaw maps projects to Telegram group IDs. The projectGroupId is a Telegram-specific negative number. This means:

• WhatsApp groups can't be used as project channels
• Discord, Slack, or other channels are excluded
• The naming (groupId, groupName) is Telegram-specific

Planned: abstract channel binding

Replace Telegram-specific group IDs with a generic channel identifier that works across any OpenClaw channel.

{
  "projects": {
    "whatsapp:120363140032870788@g.us": {
      "name": "my-project",
      "channel": "whatsapp",
      "peer": "120363140032870788@g.us",
      ...
    },
    "telegram:-1234567890": {
      "name": "other-project",
      "channel": "telegram",
      "peer": "-1234567890",
      ...
    }
  }
}

Key changes:

• projectGroupId becomes a composite key: <channel>:<peerId>
• project_register accepts channel + peerId instead of projectGroupId
• Project lookup uses the composite key from the message context
• All tool params, state keys, and docs updated accordingly
• Backward compatible: existing Telegram-only keys migrated on read

This enables any OpenClaw channel (Telegram, WhatsApp, Discord, Slack, etc.) to host a project — each group chat becomes an autonomous dev team regardless of platform.

Open questions

• Should one project be bindable to multiple channels? (e.g. Telegram for devs, WhatsApp for stakeholder updates)
• How does the orchestrator agent handle cross-channel context? (OpenClaw bindings already route by channel)

---

Other ideas

• Jira provider — IssueProvider interface already abstracts GitHub/GitLab; Jira is the obvious next addition
• Deployment integration — task_complete QA pass could trigger a deploy step via webhook or CLI
• Cost tracking — log token usage per task/tier, surface in queue_status
• Priority scoring — automatic priority assignment based on labels, age, and dependencies
• Session archival — auto-archive idle sessions after configurable timeout (currently indefinite)