peter/devclaw-gitea
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: rename 'tier' to 'level' across the codebase

Browse Source 
- Updated WorkerState type to use 'level' instead of 'tier'.
- Modified functions related to worker state management, including parseWorkerState, emptyWorkerState, getSessionForLevel, activateWorker, and deactivateWorker to reflect the new terminology.
- Adjusted health check logic to utilize 'level' instead of 'tier'.
- Refactored tick and setup tools to accommodate the change from 'tier' to 'level', including model configuration and workspace scaffolding.
- Updated tests to ensure consistency with the new 'level' terminology.
- Revised documentation and comments to reflect the changes in terminology from 'tier' to 'level'.
This commit is contained in:
Lauren ten Hoor
2026-02-11 03:04:17 +08:00
parent 1f95ad4518
commit 5df4b912c9
18 changed files with 296 additions and 278 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
lib/templates.ts
View File

@@ -101,7 +101,7 @@ All orchestration goes through these tools. You do NOT manually manage sessions,
| \`task_update\` | Update issue title, description, or labels |
| \`status\` | Task queue and worker state per project (lightweight dashboard) |
| \`health\` | Scan worker health: zombies, stale workers, orphaned state. Pass fix=true to auto-fix |
| \`work_start\` | End-to-end: label transition, tier assignment, session create/reuse, dispatch with role instructions |
| \`work_start\` | End-to-end: label transition, level assignment, session create/reuse, dispatch with role instructions |
| \`work_finish\` | End-to-end: label transition, state update, issue close/reopen. Auto-ticks queue after completion. |
### Pipeline Flow
@@ -118,19 +118,19 @@ Issue labels are the single source of truth for task state.
### Developer Assignment
Evaluate each task and pass the appropriate developer tier to \`work_start\`:
Evaluate each task and pass the appropriate developer level to \`work_start\`:
- **junior** — trivial: typos, single-file fix, quick change
- **medior** — standard: features, bug fixes, multi-file changes
- **senior** — complex: architecture, system-wide refactoring, 5+ services
- **qa** — review: code inspection, validation, test runs
- **reviewer** — QA: code inspection, validation, test runs
### Picking Up Work
1. Use \`status\` to see what's available
2. Priority: \`To Improve\` (fix failures) > \`To Test\` (QA) > \`To Do\` (new work)
3. Evaluate complexity, choose developer tier
4. Call \`work_start\` with \`issueId\`, \`role\`, \`projectGroupId\`, \`model\` (tier name)
3. Evaluate complexity, choose developer level
4. Call \`work_start\` with \`issueId\`, \`role\`, \`projectGroupId\`, \`level\`
5. Post the \`announcement\` from the tool response to Telegram
### When Work Completes
@@ -146,7 +146,7 @@ The response includes \`tickPickups\` showing any tasks that were auto-dispatche
### Prompt Instructions
Workers receive role-specific instructions appended to their task message. These are loaded from \`projects/prompts/<project-name>/<role>.md\` in the workspace. \`project_register\` scaffolds these files automatically — edit them to customize worker behavior per project.
Workers receive role-specific instructions appended to their task message. These are loaded from \`projects/roles/<project-name>/<role>.md\` in the workspace, falling back to \`projects/roles/default/<role>.md\` if no project-specific file exists. \`project_register\` scaffolds these files automatically — edit them to customize worker behavior per project.
### Heartbeats