feat(canvas): Quill charts + dashboard-aware gen-UI agent

[adamleithp]

Important

Stacked on feat/canvas (#2522) — merge that first.
This branch was cut from feat/canvas and depends on its canvas / gen-UI / Channels (project-bluebird) work; the changes here only make sense on top of it. Review #2522 first, merge it, then this PR should be rebased onto (or re-targeted at) the updated main. The base is currently main only so the full context is visible — do not merge this ahead of #2522.

What

Wires @posthog/quill-charts into the canvas gen-UI renderer and makes the chat agent anchored to the dashboard being edited.

Charts

• Bump @posthog/quill 0.3.0-beta.1 → beta.14 and add @posthog/quill-charts@beta.14.
  • beta.14 quill tokens.css supplies the --data-color-* / --color-graph-* vars the charts theme from (with dark-mode scope) — beta.1 defined none, so charts rendered with the light fallback palette.
  • beta.14 ships a broken @base-ui/react: "catalog:" dep → pinned via a pnpm override. quill-charts excluded from minimumReleaseAge (published today).
• New genui components: LineChart, BarChart, Sparkline (catalog + bodies + registry, both view & edit renderers).
  • Charts fill a flex-column wrapper with a definite height (their root is flex:1 1 0, so a plain block collapses them). Sparkline self-sizes via its height prop.
  • Theme via useChartTheme() (built-in fallback palette, dark-aware).

Agent

• Prepend the current dashboard's title to the prompt every turn so the agent stays anchored to the open board (the agent session freezes its system prompt at session start). The chat UI still shows the clean user message.
• New system-prompt rules: append-only by default (never replace/remove unless explicitly asked), build only from the catalog (Quill components/charts) unless told otherwise, prefer charts for time-bucketed metrics, and end every message with "Meep".

Test plan

• pnpm --filter code typecheck ✅, biome ✅ (also via pre-commit).
• Manual: build a dashboard with a time-series → renders a themed LineChart that respects dark mode; agent ends replies with "Meep" and appends rather than replaces.

Known follow-ups (not in this PR)

• Append-only on reloaded boards: a reopened saved dashboard starts state.spec = {} in the canvas-gen main service while the UI shows the hydrated spec — so the agent's first append builds from empty and can wipe the visible board on next render. Real fix is seeding state.spec from the saved spec at session start.
• Stat {$state}-binding crash: a binding/object Stat.value throws "Objects are not valid as a React child" → stuck "Rendering…". EditRenderer doesn't resolve {$state} bindings.
• Chart tooltip surface vars (--color-bg-surface-*, --color-text-primary-inverse) aren't defined in any beta.14 quill CSS → tooltip bg/text fall back to chart defaults.

🤖 Generated with Claude Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/canvas/subscriptions.ts:22-44
**`active` set not cleared on subscription error — thread permanently unrecoverable on same page**

When `onError` fires the subscription is dead, but `active.has(threadId)` still returns `true`. Any subsequent call to `registerCanvasSubscription` (e.g. a React remount triggered by an error boundary) returns the no-op `() => {}` guard. Because the backend's `generate()` mutation **awaits the full agent run** and emits `done` via this subscription, if the subscription dies mid-generation the mutation still resolves successfully on the backend, `isStreaming` is set to `true` in the store by `send()`, and `finish()` is never called — leaving the thread permanently stuck in streaming state without a way to recover short of navigating away.

Adding `active.delete(threadId)` inside `onError` would let tRPC's built-in reconnect logic (or a remount) establish a fresh subscription.

### Issue 2 of 3
apps/code/src/main/services/dashboards/service.ts:53-68
`listAll()` does a sequential waterfall of HTTP requests — up to `MAX_PAGES` (50) round-trips — on every call to `list(channelId)`, loading every file-system row for the whole project before filtering client-side. Even for small projects this fires at least one unfiltered API call per channel navigation. If the API supports filtering by type or path prefix, a single filtered request would be far cheaper; if not, caching the full result across the hook's 5 s `staleTime` at the tRPC layer would at least avoid the repeat scans.

```suggestion
  private async listAll(type?: string): Promise<FsEntry[]> {
    const all: FsEntry[] = [];
    // Filter by type on the first request when the API supports it.
    let suffix = type ? `?type=${encodeURIComponent(type)}` : "";
    for (let i = 0; i < MAX_PAGES; i++) {
      const res = await this.fsFetch(suffix);
      if (!res.ok) throw new Error(`Failed to list dashboards (${res.status})`);
      const page = (await res.json()) as {
        next: string | null;
        results: FsEntry[];
      };
      all.push(...page.results);
      if (!page.next) return all;
      suffix = new URL(page.next).search; // carries the pagination offset
    }
    return all;
  }
```

### Issue 3 of 3
apps/code/src/renderer/features/canvas/genui/bodies.tsx:107-130
**Superfluous `ctx` prop on data-only body components**

`GridBody`, `TableBody`, `BarListBody`, `LineChartBody`, `BarChartBody`, and `SparklineBody` all declare `ctx: BodyCtx` in their prop type but never destructure or use it. The pattern is intentional for components that have editable text (e.g. `CardBody`, `StatBody`), but for pure-data or structural components with no string props to wrap, the declaration is dead weight. This affects readability when adding new body components — it's not clear whether the omission of `ctx` usage is deliberate or a forgotten implementation.

_{Reviews (1): Last reviewed commit: "feat(canvas): Quill charts + dashboard-a..." | Re-trigger Greptile}

[greptile-apps]

active set not cleared on subscription error — thread permanently unrecoverable on same page

When onError fires the subscription is dead, but active.has(threadId) still returns true. Any subsequent call to registerCanvasSubscription (e.g. a React remount triggered by an error boundary) returns the no-op () => {} guard. Because the backend's generate() mutation awaits the full agent run and emits done via this subscription, if the subscription dies mid-generation the mutation still resolves successfully on the backend, isStreaming is set to true in the store by send(), and finish() is never called — leaving the thread permanently stuck in streaming state without a way to recover short of navigating away.

Adding active.delete(threadId) inside onError would let tRPC's built-in reconnect logic (or a remount) establish a fresh subscription.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/canvas/subscriptions.ts
Line: 22-44

Comment:
**`active` set not cleared on subscription error — thread permanently unrecoverable on same page**

When `onError` fires the subscription is dead, but `active.has(threadId)` still returns `true`. Any subsequent call to `registerCanvasSubscription` (e.g. a React remount triggered by an error boundary) returns the no-op `() => {}` guard. Because the backend's `generate()` mutation **awaits the full agent run** and emits `done` via this subscription, if the subscription dies mid-generation the mutation still resolves successfully on the backend, `isStreaming` is set to `true` in the store by `send()`, and `finish()` is never called — leaving the thread permanently stuck in streaming state without a way to recover short of navigating away.

Adding `active.delete(threadId)` inside `onError` would let tRPC's built-in reconnect logic (or a remount) establish a fresh subscription.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

listAll() does a sequential waterfall of HTTP requests — up to MAX_PAGES (50) round-trips — on every call to list(channelId), loading every file-system row for the whole project before filtering client-side. Even for small projects this fires at least one unfiltered API call per channel navigation. If the API supports filtering by type or path prefix, a single filtered request would be far cheaper; if not, caching the full result across the hook's 5 s staleTime at the tRPC layer would at least avoid the repeat scans.

Suggested change

	private async listAll(): Promise<FsEntry[]> {
	const all: FsEntry[] = [];
	let suffix = "";
	for (let i = 0; i < MAX_PAGES; i++) {
	const res = await this.fsFetch(suffix);
	if (!res.ok) throw new Error(`Failed to list dashboards (${res.status})`);
	const page = (await res.json()) as {
	next: string | null;
	results: FsEntry[];
	};
	all.push(...page.results);
	if (!page.next) return all;
	suffix = new URL(page.next).search; // carries the pagination offset
	}
	return all;
	}
	private async listAll(type?: string): Promise<FsEntry[]> {
	const all: FsEntry[] = [];
	// Filter by type on the first request when the API supports it.
	let suffix = type ? `?type=${encodeURIComponent(type)}` : "";
	for (let i = 0; i < MAX_PAGES; i++) {
	const res = await this.fsFetch(suffix);
	if (!res.ok) throw new Error(`Failed to list dashboards (${res.status})`);
	const page = (await res.json()) as {
	next: string | null;
	results: FsEntry[];
	};
	all.push(...page.results);
	if (!page.next) return all;
	suffix = new URL(page.next).search; // carries the pagination offset
	}
	return all;
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/main/services/dashboards/service.ts
Line: 53-68

Comment:
`listAll()` does a sequential waterfall of HTTP requests — up to `MAX_PAGES` (50) round-trips — on every call to `list(channelId)`, loading every file-system row for the whole project before filtering client-side. Even for small projects this fires at least one unfiltered API call per channel navigation. If the API supports filtering by type or path prefix, a single filtered request would be far cheaper; if not, caching the full result across the hook's 5 s `staleTime` at the tRPC layer would at least avoid the repeat scans.

```suggestion
  private async listAll(type?: string): Promise<FsEntry[]> {
    const all: FsEntry[] = [];
    // Filter by type on the first request when the API supports it.
    let suffix = type ? `?type=${encodeURIComponent(type)}` : "";
    for (let i = 0; i < MAX_PAGES; i++) {
      const res = await this.fsFetch(suffix);
      if (!res.ok) throw new Error(`Failed to list dashboards (${res.status})`);
      const page = (await res.json()) as {
        next: string | null;
        results: FsEntry[];
      };
      all.push(...page.results);
      if (!page.next) return all;
      suffix = new URL(page.next).search; // carries the pagination offset
    }
    return all;
  }
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Superfluous ctx prop on data-only body components

GridBody, TableBody, BarListBody, LineChartBody, BarChartBody, and SparklineBody all declare ctx: BodyCtx in their prop type but never destructure or use it. The pattern is intentional for components that have editable text (e.g. CardBody, StatBody), but for pure-data or structural components with no string props to wrap, the declaration is dead weight. This affects readability when adding new body components — it's not clear whether the omission of ctx usage is deliberate or a forgotten implementation.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/canvas/genui/bodies.tsx
Line: 107-130

Comment:
**Superfluous `ctx` prop on data-only body components**

`GridBody`, `TableBody`, `BarListBody`, `LineChartBody`, `BarChartBody`, and `SparklineBody` all declare `ctx: BodyCtx` in their prop type but never destructure or use it. The pattern is intentional for components that have editable text (e.g. `CardBody`, `StatBody`), but for pure-data or structural components with no string props to wrap, the declaration is dead weight. This affects readability when adding new body components — it's not clear whether the omission of `ctx` usage is deliberate or a forgotten implementation.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!