9d1e253f11
Auto-chaining was removed from the codebase. All docs now describe the scheduling model: work_finish transitions labels, the heartbeat's tick pass (which also fires immediately after every work_finish) detects available work and fills free slots. Removed autoChain config references. Files updated: README.md, README2.md, docs/TOOLS.md, ARCHITECTURE.md, ROADMAP.md, MANAGEMENT.md, ONBOARDING.md, lib/templates.ts https://claude.ai/code/session_01R3rGevPY748gP4uK2ggYag
97 lines
3.8 KiB
Markdown
97 lines
3.8 KiB
Markdown
# 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`
|
|
- **Levels** — which developer levels 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)
|
|
|
|
```json
|
|
{
|
|
"roles": {
|
|
"dev": { "levels": ["junior", "medior", "senior"], "workers": 1 },
|
|
"qa": { "levels": ["reviewer", "tester"], "workers": 1 },
|
|
"devops": { "levels": ["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. The scheduler follows the pipeline order when filling free slots.
|
|
|
|
### Open questions
|
|
|
|
- How do custom labels map? Generate from role names, or let users define?
|
|
- Should roles have their own instruction files (`projects/roles/<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 (partially supported now via `channel` field)
|
|
- 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.
|
|
|
|
```json
|
|
{
|
|
"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.
|
|
|
|
### 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?
|
|
|
|
---
|
|
|
|
## Other Ideas
|
|
|
|
- **Jira provider** — `IssueProvider` interface already abstracts GitHub/GitLab; Jira is the obvious next addition
|
|
- **Deployment integration** — `work_finish` QA pass could trigger a deploy step via webhook or CLI
|
|
- **Cost tracking** — log token usage per task/level, surface in `status`
|
|
- **Priority scoring** — automatic priority assignment based on labels, age, and dependencies
|
|
- **Session archival** — auto-archive idle sessions after configurable timeout (currently indefinite)
|
|
- **Progressive delegation** — track QA pass rates per level and auto-promote (see [Management Theory](MANAGEMENT.md))
|