Summary
Add a roll-up status icon to the area group headers in the VSCode sidebar's Backlog and Builders views, so an engineer can see at a glance which areas are being actively developed (and which are open to spawn into) without expanding the groups.
Unifying principle: the area-header icon is a roll-up of its children's icons. The rollup function differs because the children differ, but the rule "header summarizes what's inside it" is consistent, and every glyph keeps one meaning. Reuses the existing builder-row icon/color vocabulary — no new colors introduced.
Backlog view headers (binary)
Children are issues, so the question is "is anyone working this area?":
| State |
Icon |
Color token |
| Area has ≥1 active builder |
circle-filled |
testing.iconPassed (green) |
| No active builder (open to spawn) |
circle-outline |
disabledForeground (grey) |
The green dot is the same dot that means "live builder" on a builder row — so its meaning is reinforced, not overloaded. Grey/idle areas stay muted, so the eye skims for spawn targets.
Builders view headers (worst-of-three rollup)
Every builder area group has ≥1 builder, so binary doesn't carry — roll up to the worst child state, reusing the three icons already used on individual builder rows (builders.ts:206-210):
| If the area has… |
Icon |
Color token |
| any blocked builder |
bell |
notificationsWarningIcon.foreground (yellow) |
| else any idle/silent builder |
comment-discussion |
notificationsInfoIcon.foreground (blue) |
| else (all active) |
circle-filled |
testing.iconPassed (green) |
This matches the existing within-group sort order (blocked → idle → active), so the header icon always matches the topmost row in the group.
Both views
- Tooltip carries the detail. Backlog: "2 builders active in vscode". Builders: "1 blocked · 2 waiting · 3 active". Glanceable icon, count on hover.
Implementation notes
- VSCode extension only. The Tower web dashboard backlog isn't grouped by area today, so it's out of scope.
- No server / overview-payload change needed. The overview already carries
builders[] (each with an .area field) alongside backlog[], so both rollups are computed client-side in the tree providers.
- Backlog: derive
Set<area-with-active-builder> from overview.builders in backlog.ts, pass a boolean into BacklogGroupTreeItem, set iconPath there.
- Builders:
BuildersProvider already has each group's builders + the isBlocked/isIdle logic when it calls groupByArea; compute the worst-of rollup and pass it into BuilderGroupTreeItem.
- Keep both changes in the respective subclasses (
BacklogGroupTreeItem, BuilderGroupTreeItem), not the shared AreaGroupTreeItem base — the rollup differs per view.
Known limitation (accepted)
An area that's busy but has no remaining backlog items won't render a backlog header at all, so it can't show "working" in the Backlog view. Fine for the "where do I spawn?" goal — you only care about areas that still have spawnable work.
Relevant files
packages/vscode/src/views/area-group-tree-item.ts — shared base (do not modify the rollup here)packages/vscode/src/views/backlog-tree-item.ts / backlog.tspackages/vscode/src/views/builder-tree-item.ts / builders.ts
Summary
Add a roll-up status icon to the area group headers in the VSCode sidebar's Backlog and Builders views, so an engineer can see at a glance which areas are being actively developed (and which are open to spawn into) without expanding the groups.
Unifying principle: the area-header icon is a roll-up of its children's icons. The rollup function differs because the children differ, but the rule "header summarizes what's inside it" is consistent, and every glyph keeps one meaning. Reuses the existing builder-row icon/color vocabulary — no new colors introduced.
Backlog view headers (binary)
Children are issues, so the question is "is anyone working this area?":
circle-filledtesting.iconPassed(green)circle-outlinedisabledForeground(grey)The green dot is the same dot that means "live builder" on a builder row — so its meaning is reinforced, not overloaded. Grey/idle areas stay muted, so the eye skims for spawn targets.
Builders view headers (worst-of-three rollup)
Every builder area group has ≥1 builder, so binary doesn't carry — roll up to the worst child state, reusing the three icons already used on individual builder rows (
builders.ts:206-210):bellnotificationsWarningIcon.foreground(yellow)comment-discussionnotificationsInfoIcon.foreground(blue)circle-filledtesting.iconPassed(green)This matches the existing within-group sort order (blocked → idle → active), so the header icon always matches the topmost row in the group.
Both views
Implementation notes
builders[](each with an.areafield) alongsidebacklog[], so both rollups are computed client-side in the tree providers.Set<area-with-active-builder>fromoverview.buildersinbacklog.ts, pass a boolean intoBacklogGroupTreeItem, seticonPaththere.BuildersProvideralready has each group's builders + theisBlocked/isIdlelogic when it callsgroupByArea; compute the worst-of rollup and pass it intoBuilderGroupTreeItem.BacklogGroupTreeItem,BuilderGroupTreeItem), not the sharedAreaGroupTreeItembase — the rollup differs per view.Known limitation (accepted)
An area that's busy but has no remaining backlog items won't render a backlog header at all, so it can't show "working" in the Backlog view. Fine for the "where do I spawn?" goal — you only care about areas that still have spawnable work.
Relevant files
packages/vscode/src/views/area-group-tree-item.ts— shared base (do not modify the rollup here)packages/vscode/src/views/backlog-tree-item.ts/backlog.tspackages/vscode/src/views/builder-tree-item.ts/builders.ts