Feature: lightweight sticky notes on the canvas (file-less text nodes, Miro-style)

[orodrigobarcelos]

Summary

Add a first-class sticky note node — a small, colored, file-less text box placed directly on the canvas, the way you'd drop a note on a Miro/FigJam board.

The gap today

Cate already has two things that are almost this, but neither fits the quick-note use case:

• Editor panel — great for real notes, but it's bound to a .md file: you have to pick/create a path, and Cmd+S to persist. Too heavy for a throwaway reminder pinned next to a terminal.
• Freehand pencil — drawn strokes, not typed selectable text.

There's an "empty-workspace note" hint, but that's a placeholder, not a user-authored note.

So there's no way to just double-click empty canvas and type a note that lives in the layout.

Proposed behaviour

• Create: double-click empty canvas (or a toolbar/command-palette action, or /note if a quick-insert exists) drops an editable text node at the cursor.
• File-less: content persists inside the workspace layout (.cate/), no file on disk, no save step — like panel positions already do.
• Canvas-native: lives in world-space, pans/zooms with the canvas, drag to move, drag corner to resize.
• Styling: a small color palette (a few pastel/accent swatches), theme-aware so it reads in light and dark. Plain text or minimal markdown is enough.
• Optional: snap to the existing grid; multi-select + move with other nodes.

Why it fits Cate

The canvas is already the core surface, nodes already persist per-workspace, and there's already a color palette for regions/labels and a pencil tool — a sticky note is a natural sibling. It pairs well with multi-agent sessions: a note pinned beside a cluster of terminals to jot the plan, the target branch, or a hand-off, without spinning up an editor panel and a file for it.

This is deliberately lighter than the editor panel — the point is speed and zero friction.

Environment

• Cate 1.5.3 (Homebrew cask), macOS 15, Apple Silicon

[Anton-Horn]

We has this before but removed it as we want to limit the amount of different available nodes. This could be something for the extension system though. Maybe extend it in a way so it can render panel less nodes. Worth to give it a try!

[orodrigobarcelos]

Thanks for the pointer — I'd like to try it, so I went digging through the code first to understand what "render panel-less nodes" would actually involve. Sharing what I found, because it looks like it can't be contained inside an extension, and I'd rather agree on the approach before writing anything.

The prior art is still visible. This shipped before and was removed in 0.4.5 (997fe1bc), which deleted CanvasAnnotationComponent.tsx. The old shape was already almost exactly what I asked for:

export interface CanvasAnnotation {
  id: string
  type: 'stickyNote' | 'textLabel' | 'image'
  origin: Point; size: Size
  content: string; color: string
  fontSize?: 'sm'|'md'|'lg'|'xl'; bold?: boolean
  autoSize?: boolean
}

Notably it was a sibling collection to nodes, not a node type — and a trace of that is still in main: useCanvasInteraction.ts:284-293 still handles [data-annotation-content] in the wheel handler, with the comment "annotations aren't canvas nodes".

Three blockers for the extension route as it stands:

1. The manifest can only declare panels. normalizeManifest (src/shared/extensions.ts:195) rejects the whole manifest when panels is missing or empty, so a nodes-only extension can't load. This would need a separate contribution kind (nodes?: ExtensionNodeDef[]) plus relaxing that check.

2. The only render mechanism for extension content is an isolated <webview> (ExtensionPanel.tsx:325-333, served through proxyServer.ts). One webContents per sticky note is not viable — and the guest can't be transparent over the canvas or follow the theme (there's no theme-change event today; the color is frozen at load). So a second, lighter render path would be needed. That's the part I can't design unilaterally.

3. Every canvas node is structurally a dock. CanvasNodeState.dockLayout is required (src/shared/types.ts:56), addNode(panelId, panelType, …) requires a panelId (nodesSlice.ts:39), node membership is defined as "what's in the dockLayout" (collectPanelIds), and the chrome is hard-coded in CanvasNode.tsx (grab strip :663-694, lock/maximize/close :422-448, unfocused overlay :712-753) with border/shadow/opaque background forced in useCanvasNodeStyle.ts:104-115. A sticky note also needs to accept the first click to start editing, which that overlay currently swallows.

So my question before I start: what render mechanism do you have in mind for a panel-less extension node? Options as I see them:

• (a) A declarative contract — the extension describes the node (schema/content model) and the host renders it natively. Cheap per node, themeable, but limits extensions to what the host supports.
• (b) A lighter shared sandbox for extension-authored nodes (not one webview each).
• (c) Keep it out of the extension system entirely and reinstate a annotations sibling layer in the canvas store — smallest diff by far (no PanelType, no dockLayout, no DockStore, no culling changes), and the wheel-handler hook is still there. But I understand that layer was removed on purpose, so this is probably not what you want.

Happy to take whichever direction you prefer — and equally happy to hear "not yet". Just wanted to surface that this touches core (shared/types, canvas store, CanvasNode, manifest schema) rather than being extension-local, since CONTRIBUTING asks for the shape to be agreed before code.

[Anton-Horn]

I looked through the current code and think the declarative option is the right one. Extensions would describe a lightweight canvas item and its data, while Cate renders it natively and owns geometry, selection, persistence, and theming. A text note should be the first supported item. This avoids one webview per note and does not bring back the old annotations layer.