Proving the graft three times
One bundle, dropped into a plain HTML page, a React app and an Angular app with three different brands, is the only evidence that survives a room full of people who have each been promised portability before.
“Works across ninety-plus portfolio products” is a sentence anybody can put on a slide. The people you are saying it to have been promised portability before, usually by a vendor whose demo ran in one carefully chosen application, and the promise did not survive contact with their build. They are not going to argue with the slide. They are going to nod and then not adopt it.
The whole course has been arranged so that the claim can be made in a second form: one built file, three products that disagree with each other, three brands, and nothing edited between them. That form is falsifiable, which is the only property that makes it worth anything. This lesson is where it gets built and where you decide what evidence to keep.
What three hosts prove, and what they do not
Three is not ninety. Be the first person to say so, because somebody in the room is thinking it and the sentence is much cheaper coming from you.
What three well-chosen hosts do is convert an unfalsifiable claim into a bounded one. Instead of “it works everywhere,” you get: it ran in these three, here is the build output, here is the browser floor and why, here is what each host needed, and here is the one thing host three could not give us. That claim invites checking rather than deflecting it, and a platform engineer who checks one part of it and finds it accurate will extend credit to the rest.
Choosing hosts that disagree is what does the work. Three modern React applications prove almost nothing, because they fail in the same ways.
- A plain HTML page with a script tag. No build, no framework, no module system. If your bundle needs any of those, this host says so immediately.
- A React application. A framework that will try to own your props and your event handling. React’s own release post for React 19 (5 December 2024) states that it “adds full support for custom elements and passes all tests on Custom Elements Everywhere”, which is a fact about a version and not about React — so the host’s React version is itself one of the host facts you record.
- An Angular application, ideally from around 2018. A global stylesheet, a build configuration nobody wants to touch, and a browser floor somebody set years ago.
Where people get burned
A freshly generated Angular application proves nothing and costs you the demo. It has no legacy global stylesheet, no accumulated reset, no build pathology and no old browser floor — which is to say none of the conditions this entire course exists to handle. Secure a real one early. This is the single item on the artifact plan most likely to be discovered as missing in the week the demo is due, and there is no way to manufacture it quickly.
The rule that makes it evidence: one artifact, zero edits
The demo has exactly one rule, and everything that makes it convincing depends on holding it: the bundle is byte-identical in all three hosts. Same file, same hash, printed in the evidence. The moment you rebuild for a host, you have demonstrated three integrations rather than one graft, and the audience — correctly — assumes there will be a fourth build for the fourth product.
Two things may legitimately differ per host, and both are inputs rather than forks.
- The generated mapping stylesheet from the token-source lesson: twelve declarations, same count and same order in all three, only the right-hand sides differing.
- The host’s own configuration — where the script tag goes, what their Content Security Policy allows, how they pass you a credential. Their file, their change, recorded in your evidence as a line in the graft contract they agreed to.
Anything else that differs is a fork. Write the rule at the top of the artifact page before you start building, because the pressure to make one small host-specific exception arrives at about host two and it always looks reasonable at the time.
Why one file can behave the same in three frameworks
The reason is not that you were careful. It is that custom elements are defined by the WHATWG HTML Standard, so the browser constructs and upgrades your element and the host’s framework is a bystander. That is the load-bearing structural claim of this entire course, and it is the sentence to lead with in the room: portability here is a property of the platform, not a property of your discipline.
Which makes the browser floor the real limit, and worth stating in the evidence with vocabulary a host team can verify. Use Baseline — published by Google, which co-runs the initiative, so name that when you cite it. “Newly available” means all four core browser engines support a feature; “widely available” means it has been newly available for thirty months. A floor expressed that way can be checked by the person you handed it to. “Modern browsers” cannot, and reads as a claim you did not want examined.
Write down what it still cannot do
Put the gaps on the same page as the wins, in your own words, before anyone finds them. Three of them are already known from this course, and naming them is what separates a demonstration from a sales pitch.
- A host cannot label into your shadow root. The accessibility lesson covers what element reflection fixed and what it did not, and the honest status of the proposal that would fix the rest.
- The session arrangement in each host is a request you made of a host team, not something the component achieved on its own.
- Every browser-support and vendor-policy fact in the evidence carries a date because it will expire. Third-party cookie behaviour in particular reversed direction once already.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
You have ten seconds before someone in the room says “three is not ninety.” Say it first, and say what the three actually establish.
Check your answer
Three is not ninety, and this does not prove it runs everywhere. What it establishes is narrower and checkable: one built file, unchanged and hash-identical, rendered correctly in a plain HTML page, a React application and an Angular application from 2018, each with its own brand, each with its constraint sheet and its session path written down.
The reason to expect the fourth host to work is not the demo. It is that custom elements are defined by the HTML Standard, so the browser constructs the element and the host’s framework does not get a vote. The demo is evidence that the theory survived three hosts that disagree with each other, including one that predates most of the tooling involved.
Hands on
Build the demo and the page that defends it
Done when: One built bundle, hash printed, loads unchanged in all three hosts with three different brands and renders correctly in each — and ARTIFACT.md carries the evidence page beside the screenshots: the hash, the gzipped size, the browser floor with source and date, each host’s constraint sheet, what each host’s CSP eliminated, each host’s session path, and the three gaps named in your own words.
- Build once. Record the file hash and the gzipped byte count. Every subsequent step loads this exact file — if you rebuild, the hash changes and every screenshot taken before it is void.
- Generate the three mapping stylesheets from the token pipeline. Diff them against each other and confirm the declaration count and order match. Any host whose file is a different shape is a host where you have quietly forked.
- Load the bundle in host one, the plain HTML page. No build, no bundler, a script tag. This is the host that catches a bundle secretly depending on a module system.
- Load it in the React host. Record the React version as a host fact, then check the two things a framework can break: that your props arrive on the element, and that your events reach a listener outside the shadow root.
- Load it in the Angular host. Expect this one to fail first and to fail in the cascade, since that is what the cascade lesson predicted. Record what broke and what fixed it, because that record is worth more to a sceptical audience than the screenshot where it works.
- Assemble the evidence page in
learning/grafting-ui/ARTIFACT.md: hash, size, browser floor with source and date, three constraint sheets, three CSP notes, three session paths, three screenshots, three gaps named in your own words. Then annotate the delivery-modes reference page with what each host’s Content Security Policy actually eliminated. - Bring the evidence page into the chat, without the screenshots. If it does not stand up on its own, the screenshots were carrying it.
What this does not cover
This is the last lesson, so the honest closing is a list of what stays open rather than a promise of the next one.
What the trace itself should show — how an agent run is modelled, what a half-failed run looks like, how a tool-calling loop renders — was never this course’s subject. That belongs to Making an agent’s work legible, which builds the component this course only delivers.
The delivery table stays open on purpose. The delivery-modes reference page is the one page here meant to be revisited rather than read: every new host adds a row of experience to it, and every browser or vendor fact on it carries a date because it will expire. The third-party cookie story in the session lesson reversed direction once already, the accessibility proposal named in the Web Components module is still flag-gated in most engines, and the token format underneath your build tells implementers not to build against its current version. None of that makes the graft less shippable. It makes an undated claim about any of it the one thing you should not put in front of a host team.
Read this next — primary source
Custom elementsWHATWG HTML Standard — free, living standard
Three hosts are evidence that the bundle worked three times. This is the reason to expect a fourth: your element is defined by the HTML Standard, so the browser constructs it, not the host’s framework. Read the section in full once, at the end of the course rather than the start, because now you have hit the parts that bite — which elements may host a shadow root, what makes an element form-associated, and what the upgrade process does to an element that was already in the document when your script arrived.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.