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 — `<Canvas storage={…} onExport={…} />` — 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