From b99a1e74432a0c496fc9242152cbcbc79a66fe6a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sat, 5 Sep 2026 02:47:20 +0100 Subject: [PATCH] =?UTF-8?q?todo:=20m3e=20upstream=20said=20no=20=E2=80=94?= =?UTF-8?q?=20vendoring=20is=20the=20path?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit issue #55 and PR #56 both closed unmerged. two reasons, and the first one is ours: the PR wired one of three clipboard writes and left Inspector and PromptPanel writing directly, so it added a public surface without delivering the thing it was for. the issue text named all three sites and the PR wired one. the second is theirs and fair — embedding is not on their roadmap and it is a single-user need so far. what survives is worth more than the merge would have been: they said the adapter design is sound and they would start from it, and named what a complete version needs — the Canvas extraction plus every export path. that is a specification for the fork. Co-Authored-By: Claude Fable 5 --- todo/backburner/m3e-canvas-as-a-plugin.md | 45 ++++++++++++++++++++--- 1 file changed, 39 insertions(+), 6 deletions(-) diff --git a/todo/backburner/m3e-canvas-as-a-plugin.md b/todo/backburner/m3e-canvas-as-a-plugin.md index b44d9248..bea69767 100644 --- a/todo/backburner/m3e-canvas-as-a-plugin.md +++ b/todo/backburner/m3e-canvas-as-a-plugin.md @@ -12,8 +12,8 @@ order: 4 browser design tool for Material 3 Expressive screens that exports the design as a natural-language prompt for an AI coding tool. MIT. -Not decided. This card holds the measurements so the decision can be made from numbers rather than from -a README. Everything below was read from the code at **`cfde698`, 2026-09-04**. +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 @@ -101,15 +101,48 @@ The piece that makes it survivable is **an adapter**: Officer's panels import fr 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. -## Do this first +## Asked upstream, 2026-09-04. Declined — vendoring is the path + +[Issue #55](https://github.com/lnkiai/m3e-canvas/issues/55) asked for the seam; +[PR #56](https://github.com/lnkiai/m3e-canvas/pull/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`](https://github.com/andrepadez/m3e-canvas/tree/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 — `` — we would **depend rather than fork**, and the 3,600 owned lines shrink to a few hundred. -Two authors, three days in, MIT, actively committing, and visibly careful about structure. That is the -most receptive an upstream ever gets, and it costs one issue to find out. **The answer changes which -version of this gets built**, so it is the cheapest thing that can happen next. +**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