feat(canvas): build and securely deliver cloud artifacts

[k11kirky]

Problem

Canvases rode on the desktop "file system": the record was an untyped meta blob (code, version snapshots, pointers) merged read-modify-write, and every channel feature did two lookups — the file-system folder plus a backend channel resolved by name. The build pipeline's output was also invisible in practice: the builds poll couldn't start itself for agent-driven builds, every poll tick reloaded the iframe, and build failures hid in an edit-mode-only tooltip. The backend remodel (PostHog/posthog#73874) retires that surface; this PR moves the client onto it and fixes the build-lifecycle UX.

Changes

• New data layer: canvases are typed rows on the canvases API (ProjectApiClient + rewritten DashboardsService); source lives in server-side versions (source/versions/revert), the rendered output is the published build's artifact. The freeform store shrinks to view state; undo/redo browse server versions and revert republishes (and rebuilds).
• One channel identity: the backend channel UUID keys the sidebar, stars, CONTEXT.md instructions, feeds, task filing (now a PATCH of the task's channel), routes, and deep links. The name-matching bridge (useBackendChannel) and the file-system client are deleted. The home canvas is an is_home row seeded via a real publish; its board reads system.canvases/system.tasks.
• Build lifecycle UX: builds poll while a generation runs and refresh when it finishes; the artifact URL is pinned per build (no iframe reloads on poll ticks, with signed-URL-expiry recovery); queued/building states show elapsed time; failures surface in both view and edit modes with diagnostics and an "Ask agent to fix" affordance; the completion toast verifies the build before announcing success.
• Tidy-up: agent prompts use the canvas-*/channel-* tools; the unused local-preview pipeline (canvas-preview, the workspace-server canvas builder, its divergent contract) is deleted, with the platform manifest vendored from the server's single source of truth for the whitelist contract test; assertCanvasCapability moves to @posthog/core. Net −2k lines.

Pairs with PostHog/posthog#73874 — land the backend first, this same day (the old routes are deleted server-side).

Canvas-mode submits no longer pre-create a canvas: the channel composer used to mint an "Untitled canvas" before starting the generation task. It now just starts the task and the agent resolves the target itself — building on a matching existing canvas in the channel or creating a descriptively-named one (the building-canvases skill's resolve step). While a generation runs on a not-yet-renderable canvas, the run's chat panel opens by default, in view mode too. Cloud “Generating” state now ends with the agent's turn (via the session's prompt-pending signal) instead of persisting through the sandbox's follow-up linger window until the inactivity timeout.

Heads-up for existing sessions: the server grows a canvas scope, and OAuth grants narrowed to an app's scope ceiling enumerate their scopes at grant time (refresh never widens them) — so pre-existing sessions would 403 on every canvases call. OAUTH_SCOPE_VERSION is bumped so those sessions re-auth once and pick the scope up.

Rebased onto the code-spaces-layout work: the new spaces sidebar (search-driven Autocomplete list, hotkey slots, activity hover popover) is adapted to this PR's data layer — the personal channel is found by channel_type instead of lazily provisioned client-side, starring uses the per-user starred flag, unread state keys by channel id, and the activity feed's name→id channel bridge is removed in favor of the channel id the items now carry.

How did you test this?

Automated: full monorepo typecheck; Biome clean; check-host-boundaries (no new violations); 174 core canvas tests + 252 UI canvas tests + 681 shared tests, all updated to the new behavior (service/API mapping, home-canvas seeding incl. declared capabilities and TSX-valid seed, build lifecycle normalization, whitelist↔manifest contract, hooks over the new channel endpoints, store/view-state suites). Not done: no manual end-to-end run against a deployed backend from this session — the generate → build → artifact flow should get one manual pass in the dev stack before the pair merges.

---

Created with PostHog Code

[github-actions]

React Doctor found 4 issues in 1 file · 4 warnings.

4 warnings

src/features/canvas/freeform/FreeformCanvasView.tsx

• ⚠️ src/features/canvas/freeform/FreeformCanvasView.tsx:92 Many related useState calls prefer-useReducer
• ⚠️ src/features/canvas/freeform/FreeformCanvasView.tsx:93 Event logic handled in an effect no-event-handler
• ⚠️ src/features/canvas/freeform/FreeformCanvasView.tsx:239 Event logic handled in an effect no-event-handler
• ⚠️ src/features/canvas/freeform/FreeformCanvasView.tsx:406 State only used in handlers rerender-state-only-in-handlers

_{Reviewed by React Doctor for commit 06f431f.}

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[greptile-apps]

Too many files changed for review. (104 files found, 100 file limit)

Bypass the limit by tagging @greptile-apps to review.

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 2 · PR risk: 0/10

[posthog]

🤖 CI You Later — automated babysit pass. CI is fully green on ba30647; the branch conflicts with main.

I did not push anything. Resolving this needs a rebase + force-push (GitHub can't auto-merge, so the signed-merge API refuses), and rewriting your commits is outside what I'm allowed to do unattended. So here is the resolution I derived and verified locally instead.

The conflict

One commit on main collides: bf01d21a6 fix(channels): keep foreign canvases out of me (#3888). It makes personal-channel (#me) ownership decided solely by the creator uuid — authorUuid/createdByUuid threaded through, display names demoted to display-only, rows with no creator failing closed. It threaded that uuid through the file-system data layer that this PR deletes.

5 files conflict. channelItems.ts, channelItems.test.ts and ChannelItemRow.test.tsx auto-merge cleanly and carry main's fix as-is.

Resolution

• dashboardSchemas.ts — take this PR's side wholesale (main's hunk only touches the deleted dashboardFileMetaSchema/dashboardSummarySchema), then add createdByUuid to dashboardRecordSchema.
• dashboardsService.ts — take this PR's side for both hunks (main edited the deleted FS toRecord), then map the uuid in the new API toRecord. ApiCanvas.created_by already carries uuid, so nothing new is needed from the backend.
• useChannelItems.tsx — drop both sides of the import conflict: userDisplayName is unused after main's change, and useBackendChannel/PERSONAL_CHANNEL_NAME are deleted by this PR. The hook body auto-merges to the uuid-only version.
• useChannelItems.test.tsx — keep this PR's channel() helper and main's widened canvas(id, createdBy?, createdByUuid?) signature.
• dashboardsService.test.ts — main's two new ownership tests survive the auto-merge but call the deleted dashboardRow/fakeFs helpers. I ported them onto this PR's apiCanvas/fakeApi fake rather than dropping them; assertions unchanged.

Patch for the non-mechanical parts (apply after resolving as above)

diff --git a/packages/core/src/canvas/dashboardSchemas.ts b/packages/core/src/canvas/dashboardSchemas.ts
index 8ccabb805..4a18c7e36 100644
--- a/packages/core/src/canvas/dashboardSchemas.ts
+++ b/packages/core/src/canvas/dashboardSchemas.ts
@@ -15,8 +15,13 @@ export const dashboardRecordSchema = z.object({
   // Id of the task currently generating this canvas (freeform gen runs as a
   // dedicated task, like CONTEXT.md). null/absent = no generation in flight.
   generationTaskId: z.string().nullish(),
-  // Display name of the creator (from the backend's created_by user).
+  // Display name of the creator (from the backend's created_by user). Display
+  // only — a name is not an identity; ownership uses createdByUuid.
   createdBy: z.string().optional(),
+  // Stable uuid of the creator (from the backend's created_by user). This, not
+  // the display name, decides personal-channel ownership. Absent for rows the
+  // API returns without a creator (e.g. once the creator is deleted).
+  createdByUuid: z.string().optional(),
   createdAt: z.number(),
   updatedAt: z.number(),
   // Epoch ms the canvas was pinned to its channel; absent = not pinned.
diff --git a/packages/core/src/canvas/dashboardsService.test.ts b/packages/core/src/canvas/dashboardsService.test.ts
index 007b74bd4..f60e25919 100644
--- a/packages/core/src/canvas/dashboardsService.test.ts
+++ b/packages/core/src/canvas/dashboardsService.test.ts
@@ -75,6 +75,30 @@ describe("DashboardsService.list", () => {
     });
     expect(rows[0].createdAt).toBe(Date.parse("2026-07-01T00:00:00Z"));
   });
+
+  it("maps the backend creator uuid onto records", async () => {
+    const { api } = fakeApi({
+      "canvases/?channel=chan-1": [
+        apiCanvas({ created_by: { uuid: "creator-uuid" } }),
+      ],
+    });
+
+    const [result] = await new DashboardsService(api).list("chan-1");
+
+    expect(result.createdByUuid).toBe("creator-uuid");
+  });
+
+  // The backend sends `created_by: null` once the creator is deleted. Leaving
+  // the uuid undefined is what makes such a row fail closed out of #me.
+  it("leaves the creator uuid undefined when the row has no creator", async () => {
+    const { api } = fakeApi({
+      "canvases/?channel=chan-1": [apiCanvas({ created_by: null })],
+    });
+
+    const [result] = await new DashboardsService(api).list("chan-1");
+
+    expect(result.createdByUuid).toBeUndefined();
+  });
 });
 
 describe("DashboardsService.ensureHomeCanvas", () => {
diff --git a/packages/core/src/canvas/dashboardsService.ts b/packages/core/src/canvas/dashboardsService.ts
index 650ce8d3c..facb66046 100644
--- a/packages/core/src/canvas/dashboardsService.ts
+++ b/packages/core/src/canvas/dashboardsService.ts
@@ -51,6 +51,7 @@ interface ApiCanvas {
   current_version_id: string | null;
   published_build_id: string | null;
   created_by?: {
+    uuid: string;
     first_name?: string | null;
     last_name?: string | null;
     email?: string | null;
@@ -92,6 +93,9 @@ function toRecord(api: ApiCanvas): DashboardRecord {
     context: api.context ?? "",
     generationTaskId: api.generation_task_id,
     createdBy: creatorLabel(api.created_by),
+    // Undefined when the API returns no creator, which is what makes such a row
+    // fail closed out of the personal channel (see isOwnedBy in channelItems).
+    createdByUuid: api.created_by?.uuid,
     createdAt: toEpoch(api.created_at) ?? 0,
     updatedAt: toEpoch(api.updated_at) ?? 0,
     pinnedAt: toEpoch(api.pinned_at),

Verified on the resolved tree: pnpm typecheck clean (24/24 packages) · biome check packages/core packages/ui clean · check-host-boundaries no new violations · 2603 core tests and 2327 UI tests pass (incl. 182 core + 289 UI canvas tests).

Still needs you

1. The rebase itself — I can't force-push over your commits.
2. @veria-ai's High finding on BuiltCanvas.tsx:58 (iframe bridge survives self-navigation) — left alone deliberately. A MessageChannel handshake or teardown-on-navigate changes the host↔artifact protocol on both sides, and this PR ships multi-page artifacts with navigate intents, so "tear down on navigation" isn't obviously safe. Your call, not mine. Note the wildcard postMessage target can't be tightened here — sandbox="allow-scripts" without allow-same-origin gives the frame an opaque origin.

I'll re-check on the next pass and won't repeat this comment.

[posthog]

👋 Visual changes detected for this PR.

Review and approve in PostHog Visual Review

If these changes are unexpected, they may be caused by a flaky test or a broken snapshot on master. Don't approve — rerun the job or wait for a fix.

[charlesvien]

Hey @k11kirky, we've migrated this repo into the PostHog/posthog monorepo, so this PR needs to be recreated there.

Easiest path: check out the monorepo and run the /porting-code-prs skill with your agent pointed at this PR. It has the migration guide and path remappings baked in so the agent doesn't have to figure them out. You don't strictly need it though, just asking your agent to port the PR works fine too.

Shout if you get stuck.