Adjust config.json to add colors. Rename "HUB" to "DISPATCH"

[pi0neerpat]

No description provided.

[pi0neerpat]

@claude review

[claude]

Claude finished @pi0neerpat's task in 2m 34s —— View job

---

PR Review

• Gather context
• Read key changed files
• Analyze changes
• Post review feedback

---

This is a well-executed refactoring. The rename is systematic, backward compat is handled at all the right layers, and the color architecture improvement is a net positive.

Summary

Two themes:

1. Rename HUB → DISPATCH across env vars, config fields, internal constants, and sentinel strings
2. Config-driven repo colors — replaces the hardcoded repoIdentityColors static map with per-repo color fields in config.json, surfaced through the API

---

What's Good

Backward compat is thorough:

• hub-stop.js reads DISPATCH_* env vars with || HUB_* fallback
• server.js reads DISPATCH_ROOT || HUB_DIR
• parsers.js normalizes legacy hubRoot → dispatchRoot on load
• The exit code sentinel regex now matches both __DISPATCH_CLAUDE_EXIT_CODE__ and __HUB_CLAUDE_EXIT_CODE__
• New test covers the hubRoot → dispatchRoot migration path

Color architecture is better: Moving from repoIdentityColors (a hardcoded map keyed by repo name) to config-defined colors per repo means teams can define their own accent colors without touching source code. ActivityFeed and ActivityTimeline now use item.color directly from the API response — cleanest pattern in the PR.

---

Issues

1. API response field rename is a breaking change (no backward compat)

/api/overview and /api/catalog both now return dispatchRoot instead of hubRoot. Unlike the config file (which has a migration shim in parsers.js), the API response has no backward compat — external clients reading response.hubRoot will silently get undefined.

// dashboard/server.js ~line 800
res.json({ dispatchRoot: config.dispatchRoot || DISPATCH_ROOT, ... })
// and ~line 1582
res.json({ dispatchRoot: config.dispatchRoot || DISPATCH_ROOT, ... })

Low risk since this is an internal tool, but worth noting if any agents or external integrations read these fields.

2. Subtle behavior change in AllTasksView repo selector

dashboard/src/components/AllTasksView.jsx ~line 293:

// Before:
style={newTaskRepo && repoIdentityColors[newTaskRepo]
  ? { color: repoIdentityColors[newTaskRepo] }
  : { color: 'var(--muted-foreground)' }}

// After:
style={newTaskRepo
  ? { color: getRepoColor(overview, newTaskRepo) }
  : { color: 'var(--muted-foreground)' }}

When newTaskRepo is set but the repo has no color in config, the old code fell back to muted-foreground (implying "no special color"). The new code falls back to DEFAULT_REPO_COLOR = 'var(--primary)', which gives the button an active-looking accent. Minor visual impact, but existing repos without color defined will now show primary accent instead of muted text. Fix this →

3. SchedulesView uses an inline pattern instead of getRepoColor

dashboard/src/components/SchedulesView.jsx ~line 231:

const repoColor = repos.find(r => r.name === schedule.repo)?.color || DEFAULT_REPO_COLOR

Other components use getRepoColor(overview, schedule.repo) consistently. Minor inconsistency but worth aligning for maintainability.

---

Nits

• terminal.js renames the terminal header from SCRIBULAR HUB → SCRIBULAR DISPATCH (good, matches the rename intent)
• parsers.js: The loadConfig function destructures hubRoot from the raw JSON and remaps it to dispatchRoot. The rawRest spread ensures hubRoot is excluded from the output — clean migration path.
• All repoIdentityColors references have been removed from the frontend — no stragglers found.

---

Verdict

Approve with the minor behavior change in AllTasksView worth a quick look. The color fallback difference (#2 above) could affect repos that don't yet have color defined in their config.
| Branch: ui-tweaks