feat(foreman): label/assignee heuristics driven by agents.json #452

Closed
opened 2026-04-27 13:49:16 +00:00 by claude-desktop · 0 comments
Collaborator

User story

As an operator, I want foreman's label-suggestion regex rules and assignee-fallback table to live in agents.json, so that I can teach foreman new labels (e.g. area:db, area:auth) and route them to the right agent type without editing domain/agent/foreman.ts.

Why: foreman.ts:652-671 has hardcoded regexes (design|penpot|ui, secur|auth, dashboard|admin, api|endpoint, test|spec) and priority-ordered assignee picks (design→designer, security→reviewer, default→dev). Each new agent type or area requires a code edit.

Acceptance criteria

Schema

  • agents.json::foreman.label_rules: Array<{ pattern: string; label: string }> — case-insensitive regex matched against issue body
  • agents.json::foreman.assignee_rules: Array<{ when_label?: string; when_pattern?: string; assign_to: string }> — first match wins; assign_to is an agent type name
  • agents.json::foreman.default_assignee: string — fallback when no rule matches (current default: boss)
  • Defaults match current hardcoded behaviour exactly

Code

  • foreman.ts::suggestLabels and suggestAssignee read from resolved config (not const arrays in source)
  • Tests cover: each existing rule still routes correctly via the config-driven path

Out of scope

  • ML-based suggestion (still pure rules)
  • Editing rules in dashboard (Phase 4)

References

  • apps/server/src/domain/agent/foreman.ts:652-671
  • docs/foreman.md
  • Audit category 1 (MED)
## User story As an operator, I want foreman's label-suggestion regex rules and assignee-fallback table to live in `agents.json`, so that I can teach foreman new labels (e.g. `area:db`, `area:auth`) and route them to the right agent type without editing `domain/agent/foreman.ts`. **Why:** `foreman.ts:652-671` has hardcoded regexes (`design|penpot|ui`, `secur|auth`, `dashboard|admin`, `api|endpoint`, `test|spec`) and priority-ordered assignee picks (design→designer, security→reviewer, default→dev). Each new agent type or area requires a code edit. ## Acceptance criteria ### Schema - [ ] `agents.json::foreman.label_rules: Array<{ pattern: string; label: string }>` — case-insensitive regex matched against issue body - [ ] `agents.json::foreman.assignee_rules: Array<{ when_label?: string; when_pattern?: string; assign_to: string }>` — first match wins; `assign_to` is an agent type name - [ ] `agents.json::foreman.default_assignee: string` — fallback when no rule matches (current default: `boss`) - [ ] Defaults match current hardcoded behaviour exactly ### Code - [ ] `foreman.ts::suggestLabels` and `suggestAssignee` read from resolved config (not const arrays in source) - [ ] Tests cover: each existing rule still routes correctly via the config-driven path ## Out of scope - ML-based suggestion (still pure rules) - Editing rules in dashboard (Phase 4) ## References - `apps/server/src/domain/agent/foreman.ts:652-671` - `docs/foreman.md` - Audit category 1 (MED)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
charles/claude-hooks#452
No description provided.