platform/todo/backburner/m3e-canvas-as-a-plugin.md

id, title, theme, status, created, date_source, order

id	title	theme	status	created	date_source	order
backburner/m3e-canvas-as-a-plugin	M3E Canvas as a plugin — sketch a UI, hand the prompt to the agent	backburner	open	2026-09-04	stated	4

M3E Canvas as a plugin. github.com/lnkiai/m3e-canvas — a browser design tool for Material 3 Expressive screens that exports the design as a natural-language prompt for an AI coding tool. MIT.

The upstream question is now answered — see below; vendoring is the path. The rest is still open. This card holds the measurements so the decision is made from numbers rather than from a README. Everything below was read from the code at cfde698, 2026-09-04.

Why it is interesting

Its output is a prompt you paste into Claude. Officer is the thing that removes the paste — the export button could open a chat session with the prompt already in it, pointed at a project directory on this machine. That last step is the only part Officer uniquely adds, and it is the whole reason to bother. The canvas already works standalone today.

What it actually is

size	65 files, 14,822 lines of TS/TSX
deps	next 16.3.4, react 19.2.8, motion ^13.1.1, html-to-image ^1.11.13
licence	MIT
storage	localStorage only, no backend

Next.js is not actually there. The entire codebase imports it once, and it is a type-only import: import type { Metadata, Viewport } from "next" in app/layout.tsx. Eighteen files carry 'use client'. So it is a client-side React SPA that happens to be scaffolded in Next — there is nothing to strip, and porting means giving it a different mount point.

That is the finding that changes the estimate. An earlier read of the README concluded "weeks of work, own a fork forever", and that was wrong.

The fork line falls on a file boundary

app/page.tsx imports about twenty modules, every one a named export through the @/ alias, and reaches into no internals. lib/tokens.ts is the shared spine with 16 importers. app/ holds exactly one file that matters.

	lines
app/page.tsx	3,433	the whole editor: 15 components, 103 hook calls. Yours.
lib/ai.ts	~200	Delete it — stores provider API keys in localStorage. Officer has a secret store and the agent.
lib/tokens.ts	1,614	Material 3 tokens. Data. Vendor.
components/M3Node.tsx	1,233	the component renderer. Vendor.
components/Inspector.tsx	1,171	Vendor.
lib/prompt.ts	1,151	the export engine. Vendor.
components/Preview.tsx	899	Vendor.
components/ui.tsx	882	Vendor.
rest	~4,200	Mobile, i18n, tidy, Toolbar, color, shapes, theme, project. Vendor.

~3,600 lines owned, ~11,200 vendored — and the split means something. What is vendored is "what a Material 3 component looks like and how to describe it in words", where upstream's value accumulates and we have no wish to innovate. What is owned is "where does this live in the workspace, whose is it, and what happens on export", where upstream can never help because it does not know Officer exists.

So deep integration and tracking upstream are not in tension. The integration work lives entirely in the one file that was always going to be rewritten.

The export point is clean

buildPrompt(doc: Doc, widths: Record<string, number>, onlyFrameId?: string, lang: Lang): string
effectivePrompt(doc, widths, lang): string

Two pure functions in lib/prompt.ts. Doc in, string out, no side effects. No postMessage bridge and no clipboard interception needed — call the function. Today it ends in navigator.clipboard.writeText in three places; that is what gets replaced.

Doc is plain serialisable JSON (lib/project.ts already downloads and reloads it), so persisting to a plugin table instead of localStorage is nearly free. Current keys: DOC_KEY and UI_KEY in page.tsx, m3e:ai, and m3e:sec:<id>.

The upstream problem, measured

This is the part that makes it a backburner card rather than a build.

• 37 commits, 3 days old — first 2026-09-02, and 22 of them landed on 2026-09-04, the day this was read.
• Two human authors (lnkiai 25, CQMHV 10) plus dependabot.

It is under heavy active development right now. The export surface will churn, and no amount of discipline on our side changes that. "Vendor it and track upstream" assumes an upstream that has settled, and this one has not started.

If it is vendored anyway

web/vendor/m3e/, committed with upstream URL, commit SHA and date in a README beside it. The precedent is already in the tree — plugins/jellyfin/web/vendor/ and public/vendor/pako/.

The piece that makes it survivable is an adapter: Officer's panels import from one adapter.ts that re-exports from vendor/, never from vendor/ directly. An upstream rename then costs one file instead of twenty. Updating is: re-copy, read the diff, fix the seam.

Asked upstream, 2026-09-04. Declined — vendoring is the path

Issue #55 asked for the seam; PR #56 implemented the smaller half of it. Both closed unmerged on 2026-09-05. The reply is worth reading in full, but the two reasons were:

1. The PR did not actually unblock embedding. It wired one of the three clipboard writes — app/page.tsx — and left components/Inspector.tsx:443 and components/PromptPanel.tsx:35 writing directly. So it "adds a public surface I'd have to keep stable" without delivering the thing it was for. That was our error, not a judgement call: the issue text named all three sites and the PR wired one.
2. Embedding is not on their roadmap, and it is a single-user need so far. Fair on both counts.

What they said they would want if that changes, quoted because it is the specification for any future attempt:

If I decide to support embedding I'd want to do it in one piece: the Canvas extraction plus the adapter wired into every export path. Your design for the adapter is sound and I'd start from it then.

So the adapter design survives — it is validated by the person who would have to maintain it — and the work it needs is known: the file move plus all three export paths, not one of them.

The branch is on the fork at andrepadez/m3e-canvas embeddable-canvas, two commits, typecheck and build green. Worth keeping: if this is vendored, that is the diff to apply on top, extended to the other two call sites.

What this settles

Vendor, do not depend. The upstream door is open in principle and shut in practice, so the fork is the only route to the integration — which is what the split below was already designed for. Nothing about the file-boundary analysis changes; only the hope of upstreaming the shell does.

If it is picked up anyway

Open an issue asking upstream to make the seam explicit. If page.tsx grew an entry point taking the persistence layer and the export sink — <Canvas storage={…} onExport={…} /> — we would depend rather than fork, and the 3,600 owned lines shrink to a few hundred.

Answered: no, for now. Recorded above. Asking cost an afternoon and bought a specification for what upstream would accept, plus confirmation that the adapter shape is right — which is a good return on a declined PR.

Open questions

1. Is this a design tool that lives in Officer, or the front end of "sketch it and the agent builds it"? If the second, page.tsx is where we deliberately diverge, and adopting the fork is the right frame from day one rather than something discovered in six months.
2. Whose designs are they? Doc is per-user data. Multi-user makes that a permissions question, and the plugin table answers it in a way localStorage cannot.
3. Does the phone editor survive the port? components/Mobile.tsx (534 lines) is a separate phone-optimised editor. Officer's mobile story is a native app, so this may be redundant or may be the best part.
4. An iframe was considered and rejected. It buys a day and costs the function call, the theming, the persistence, and forces back the clipboard round-trip the whole idea exists to remove. Recorded so it is not re-proposed as the cheap option.