Surface materialised UIs: canvas library / Omadia Graph integration with user assignments

[Weegy]

Summary

Once canvases become durable, shareable objects (#6) with lifecycle (#8) and replayable recipes (#11), they are first-class entities — but there is currently no place where a user can see them. A canvas exists only inside the session that has it open.

This issue proposes surfacing all materialised UIs (persisted canvases) in a browsable view, including their user assignments (owner + grantees), with two candidate presentations to evaluate:

• (A) Integrate into the Omadia Graph — canvases appear as nodes in the kernel's graph alongside the entities they were built from, with edges to their data sources (via recorded dataRefs / recipe tool calls) and to the users they are assigned to.
• (B) Dedicated canvas overview — a separate view (canvas library) in the host app listing all canvases the user owns or has been granted, with assignment info per canvas.

These are not mutually exclusive — (B) is the likely v1, (A) the richer follow-up once canvases carry enough provenance metadata (#11 provides exactly that).

Motivation

• Discoverability: a grantee who receives a share (Canvas sharing: grant read access to other users (snapshot + live modes) #6) needs somewhere to find it; an owner with twenty canvases needs an inventory to manage, re-open, share, and delete (Delete canvases from the Omadia UI (per-user removal, full delete on last reference) #8) them.
• Accountability: "who can see this canvas?" should be answerable at a glance — the assignment list is the management UI for the grant model.
• Provenance (graph variant): a canvas built from specific records/tools is semantically connected to those entities. Showing it in the graph makes materialised UIs part of the tenant's knowledge surface rather than orphaned artifacts.

Proposed behavior (v1 — canvas overview)

1. A canvas library view in the host app: every canvas the user holds a reference to (owner or grantee), with title, preview/thumbnail of the last revision, owner, shared-with list, last-refreshed timestamp, and refreshable/static state (Deterministic refresh for data-driven canvases (no LLM turn) #5/Bind the originating query to the canvas: persisted tool-call recipes for deterministic replay #11).
2. Per-canvas actions from the list: open (attach a surface), refresh (Deterministic refresh for data-driven canvases (no LLM turn) #5), share / manage assignments (Canvas sharing: grant read access to other users (snapshot + live modes) #6), delete (Delete canvases from the Omadia UI (per-user removal, full delete on last reference) #8) — the library is the single management surface for the canvas lifecycle.
3. User assignments inline: owner badge + grantee list with mode (snapshot/live); owners can revoke from here. This is the UI for the grant model rather than a separate admin screen.
4. Tenant-scoped, permission-aware: users only ever see canvases they hold a reference to; there is no tenant-wide browse in v1.

Graph integration (follow-up scope)

• Canvas node type in the Omadia Graph with edges: materialised-from → data entities/tools (derived from the recipe, Bind the originating query to the canvas: persisted tool-call recipes for deterministic replay #11), assigned-to → users (derived from grants, Canvas sharing: grant read access to other users (snapshot + live modes) #6), produced-in → originating session/turn.
• Opening the node attaches the canvas; graph filters ("show all UIs assigned to user X", "all canvases built on entity Y") fall out of the edge model.
• Requires kernel-side support — should be split into a companion issue on byte5ai/omadia when picked up.

Open questions

• Thumbnails: render-side snapshot of the last revision (cheap, may go stale) vs. live mini-render (costly)? A stale thumbnail with the last-refreshed timestamp is probably fine for v1.
• Where does the library live in the host app shell — alongside the session/start view, or as a pane the agent can also open (i.e., is the library itself a canvas)?
• Does the graph variant belong in this repo at all, or entirely kernel-side with the host app only deep-linking into it?

Related

• Canvas sharing: grant read access to other users (snapshot + live modes) #6 (sharing — grants are the "user assignments" this view displays and manages)
• Delete canvases from the Omadia UI (per-user removal, full delete on last reference) #8 (deletion — the library is the natural place to delete from)
• Bind the originating query to the canvas: persisted tool-call recipes for deterministic replay #11 (recipes — provide the provenance edges for the graph variant)
• Deterministic refresh for data-driven canvases (no LLM turn) #5 (refresh — per-canvas refresh state and action in the list)

[Weegy]

v1 (canvas overview) implemented in PR #10 (cfe11c1):

• The sidebar gains a ▦ Bibliothek entry opening a grid overlay of every canvas the user holds a reference to: color dot + title, a live mini-render of the last known tree (the registry already materialises trees client-side, so the thumbnail open question resolves to neither option — we render the real tree scaled down, inert; never stale, no render pipeline), and a structural meta line (tables · rows · charts).
• Per-canvas actions: click-to-open (attaches the surface via slot switch) and delete with the same two-step in-place confirm as the rail (Delete canvases from the Omadia UI (per-user removal, full delete on last reference) #8 semantics incl. registry update). Refresh stays one click away after opening (Deterministic refresh for data-driven canvases (no LLM turn) #5 chrome affordance).
• Placement open question: v1 ships as a host-app overlay, not a canvas — revisit when the agent should be able to open it.
• Permission scope: purely client-side over the per-user registry, so users only ever see canvases they hold — tenant-wide browse explicitly out (as specced).

Verified E2E against the live kernel: 4 canvases listed with live previews and correct metas, preview click opens the canvas, delete confirm arms without deleting.

Deferred, as specced: owner badge + grantee list and revoke (#6 — no grants exist pre-sharing, every canvas has exactly one user today), last-refreshed timestamp + refreshable state per card (needs per-canvas dataRef state outside the active session), and the Omadia-Graph variant (kernel-side companion issue when picked up — #11 recipes now provide the provenance for materialised-from edges).