Show the BB project in the GitHub PR table, ordered by project name

[abdoutelb]

What was wrong

The GitHub panel's Pull requests tab lists every tracked repo's PRs in one table, but nothing on a row said which BB project it belonged to. On a workspace with more than one project the tab reads as a flat pile of unrelated PRs, and the only way to tell them apart is recognising the PR title.

The data was already almost there: discoverRepos() walks BB project sources to find each repo's origin remote, so it knows exactly which project a repo came from — it just kept the project id and dropped the name, and nothing downstream grouped by it.

What changed

• plugins/github/server.ts — repo discovery keeps projectName alongside projectId; repoInfoSchema (and so the status RPC output) carries it. BbProjectSummary picks up name, which projects.list() already returns.
• plugins/github/project-order.ts (new) — projectNamesByRepo() resolves owner/repo → project name (skipping blank/absent names so a lookup miss means "no project"), and sortByProjectName() applies the ordering. Shared by the server and the app bundle so the panel and the CLI cannot drift apart.
• plugins/github/app.tsx — the PR table gains a Project column between ID and Title, and ListView orders pull requests by project name: case-insensitive, repos with no BB project last, and the sort is stable so the cache's newest-updated-first order survives inside each project. A row with no project renders an em dash. The issue table is deliberately unchanged — sorting issues by project would have replaced their newest-first default, which nothing asked for.
• CLI: bb github prs prints the project column in the same order (- where a repo has no project); bb github repos prints the project name next to its id. Both USAGE and the registered command summary say so, which is what the plugin-commands skill surfaces to agents.
• plugins/github/README.md documents the column, the ordering, and the new CLI output.
• plugins/github/package.json — version 0.2.1 → 0.3.0, per docs/official-plugin-release-process.md ("bump when the change is user-visible").

No wire change: HOST_DAEMON_PROTOCOL_VERSION is untouched. The plugin's server and app bundles ship together, so the RPC contract addition needs no compatibility step. Nothing outside plugins/github reads repoInfoSchema or the CLI output.

How you verified

pnpm exec turbo run typecheck test build --filter=bb-plugin-github

23 tests pass; typecheck and the plugin build are clean.

New tests, both of which I confirmed fail before this change and pass after:

• project-order.test.ts — grouping, stability inside a project (two repos of one project stay interleaved as the cache ordered them), project-less repos last, blank names treated as absent, case-folded ordering that still keeps one project together, a repo missing from the tracked list, and no mutation of the caller's array.
• app.test.tsx — three jsdom cases rendering the real GithubPanel through the plugin SDK's test harness: the column is present and rows come out in project order on the PR tab, each row is labelled with its repo's project (em dash where there is none), and the Issues tab has no Project column. Reverting just the sort fails the first case; forcing the column off fails the first two.

app.test.tsx needed two bits of test plumbing: @testing-library/react + jsdom devDependencies (matching the other plugins that have an app.test.tsx), and a resolve.alias for @/ in vitest.config.ts — esbuild reads that path from tsconfig.json when bundling the plugin, but vitest does not, so importing app.tsx failed to resolve without it.

I also rendered the panel in headless Chrome with the compiled dist/app.css and the app's theme tokens to check the column visually in light and dark, at the @[48rem] container breakpoint and below it.

Filed from Multica issue POLL-3; there is no GitHub issue for it.

AGENT GENERATED: by Claude Opus 5

[abdoutelb]

Screenshots

Pull requests — the new Project column

Six PRs across four tracked repos. The cache handed them over flat, newest-updated first — #1948, #12, #204, #77, #1943, #201. The table regrouped them:

ID	Project	Updated
#1948	bb	2h ago
#1943	bb	12h ago
#204	Payments API	7h ago
#201	Payments API	1d ago
#77	Storefront	9h ago
#12	—	5h ago

Projects in name order, newest-updated first inside each project, and acme/scratch — tracked through extraRepos, attached to no BB project — renders an em dash and sorts last.

Same table, light mode

Issues — deliberately unchanged

No Project column, still newest-first. Adding the column here would have been easy, but ordering issues by project would have replaced their newest-first default, which nothing asked for. ItemsTable takes showProject off kind === "pr", so flipping it is a one-line change if reviewers want it.

How these were captured

Not a screenshot of a running bb app — the environment I ran in has no authenticated bb instance. These are the real components: GithubPanel rendered through @get-bb/plugin-sdk/testing/app, then screenshotted in headless Chrome against the plugin's compiled dist/app.css, the theme tokens from apps/app/src/components/ui/theme.css, Tailwind's preflight, and Inter Variable, at a container width above the @[48rem] breakpoint. Layout, spacing, colors and column widths are what the built plugin produces; the repos, projects, PR titles and numbers are fixtures, not live GitHub data.

The images are served from the assets/pr-1962-screenshots branch on the fork (an orphan commit holding only the three PNGs, not part of this PR's diff) because there is no API for attaching images to a comment. Deleting that branch breaks the images above.

AGENT GENERATED: by Claude Opus 5