vscode: 'Open Builder Terminal' and 'Send Message' Quick Picks show internal builder id instead of issue # + title

[amrmelsayed]

Problem

The Codev VSCode extension has nine command-palette Quick Pick pickers that ask the user to select a builder. Seven of them render each row as #<issueId> <issueTitle> (with optional context in the description), matching the format used everywhere else in the extension (sidebar rows, hover tooltips, panel labels). Two outliers render only the internal builder name (e.g. pir-1333), which is meaningless to the user — they have to remember which issue maps to which internal id.

What the user sees

Command	Renders	User experience
Codev: Open Builder Terminal	pir-1333	"Which one was that again?"
Codev: Send Message to Builder	pir-1333	Same

Compare to the seven correct ones (Approve Gate, Cleanup Builder, View Diff, Run Worktree Setup, Run Dev, Open Worktree Window, Open Worktree Folder), which all show #909 architect: treat area/* labels as a first-class organizing concept and let the user pick by issue meaning rather than internal id.

Audit (current state)

The correct pattern — 7 pickers

Command	File	Label format
Approve Gate	packages/vscode/src/commands/approve.ts:90-97	#<id> <title> + description blocked on <gate>
Cleanup Builder	packages/vscode/src/commands/cleanup.ts:39-43	#<id> <title> + description <phase>
View Diff	packages/vscode/src/commands/view-diff.ts:377-380	#<id> <title>
Run Worktree Setup	packages/vscode/src/commands/run-worktree-setup.ts:40-46	#<id> <title>
Run Dev	packages/vscode/src/commands/run-worktree-dev.ts:73-79	#<id> <title>
Open Worktree Window	packages/vscode/src/commands/open-worktree-window.ts:67-73	#<id> <title>
Open Worktree Folder	packages/vscode/src/commands/open-worktree-folder.ts:56-62	#<id> <title>

The broken pattern — 2 pickers

Command	File:line	Current code
Open Builder Terminal	packages/vscode/src/extension.ts:539-542	builders.map(b => ({ label: b.name, id: b.id, terminalId: b.terminalId! }))
Send Message to Builder	packages/vscode/src/commands/send.ts:22-25	builders.map(b => ({ label: b.name, id: b.id }))

Fix

Bring both outliers in line with the established pattern. Mechanically:

extension.ts:539-542 — change from:

builders.map(b => ({ label: b.name, id: b.id, terminalId: b.terminalId! }))

to:

builders.map(b => ({
  label: `#${b.issueId ?? b.id} ${b.issueTitle ?? ''}`,
  description: b.phase,
  id: b.id,
  terminalId: b.terminalId!,
}))

send.ts:22-25 — change from:

builders.map(b => ({ label: b.name, id: b.id }))

to:

builders.map(b => ({
  label: `#${b.issueId ?? b.id} ${b.issueTitle ?? ''}`,
  description: b.phase,
  id: b.id,
}))

The description: b.phase addition matches what Cleanup Builder does (which is also a multi-builder action where the user benefits from seeing each builder's phase at-a-glance). Verify both call sites' data sources include issueId, issueTitle, and phase — they come from the same client.getWorkspaceState(workspacePath) endpoint the seven correct pickers use, so the fields should already be populated.

Acceptance

• Invoking Codev: Open Builder Terminal shows builder rows formatted as #<id> <title> with <phase> in the description.
• Invoking Codev: Send Message to Builder shows builder rows formatted the same way.
• When issueId is missing (degenerate state — should be rare), the picker falls back to the internal name like the seven correct pickers already do via b.issueId ?? b.id.
• No regression to the seven correct pickers.
• No regression to the downstream action — Open Builder Terminal still opens the right terminal; Send Message still sends to the right builder.

Out of scope

• Standardising on a shared pickBuilder helper across all nine call sites (worthwhile follow-up; this issue stays surgical to fix the two bad rows without restructuring the seven good ones).
• Changes to the sidebar tree, hover tooltips, or any non-Quick-Pick surface.
• Per-row Quick Pick buttons (open in browser, copy id, etc.) — separate enhancement.

Why BUGFIX

Mechanical fix, ~10 LOC across two files, no design ambiguity left after this issue body, no architectural decisions. The seven correct call sites already prove the pattern works and the data is available.

[amrmelsayed]

On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).