SvelteKit routes, edited in the +page.svelte that rendered them

Routes are the case it is built around. The cross-stack parity test drives a real SvelteKit fixture — a src/routes/about/+page.svelte served at /about — and all four write lanes land in that file. The fixture deliberately ships the src/app.html shell alongside it, because resolving a route edit to the shell instead of the route is the specific failure the route-first ordering exists to prevent. Plain Svelte components under src/lib are stamped the same way and edit the same way.

Into that route's own svelte:head block, creating one if the route has none. SvelteKit hoists a svelte:head into the document head for exactly the routes that render it, so for a +page.svelte that is precisely the one route it resolves to — which makes it the only place a per-page value can honestly go. src/app.html is the site-wide shell and stays the fallback for a route whose file cannot be resolved at all. Build output such as .svelte-kit is refused as a write target outright, since the next build erases it.

Text from a rune, a store or a prop is refused, by name. PortBay reads your source, not Svelte's runtime semantics, so an h1 whose contents are an expression is a text run holding braces — and rewriting those bytes would either destroy the binding or write a literal where a value belongs. The refusal says it is a template expression and points you at the source. Static copy in the same file edits normally, so in practice you edit the words you wrote and change the data for the words you computed.

Yes. A .svelte file is markup-first — the whole document is one markup region, with script and style as blocks inside it — and in markup a capitalised tag is a component and nothing else. So the usage site is stamped safely, and an element that Team rendered still traces back to the line where you used it. A .jsx or .tsx file does not get that tier, because the same tag shape there can be a TypeScript generic parameter list. It is the clearest concrete advantage the Svelte and Vue lanes have over the React one.

Every rendered copy carries the same coordinate, because they all came from the same line of your template. So editing one row edits the template, and therefore every row — which is usually what you meant, and when it is not, the thing to change is the data. The case that genuinely gets hard is an unstamped project, where PortBay has to fall back to a unique id or to counting same-tag siblings on the page; a loop makes those counts disagree with the source and PortBay hands you a picker instead of guessing which occurrence you meant.

No. The stamping plugin is compiled into the PortBay binary, written out to PortBay's own data directory, and handed to your dev server through a config generated outside your repository. There is no package to add and none to remove: uninstall PortBay and your package.json, lockfile and node_modules are byte-for-byte what they were. It is not on npm and is not meant to be, because nothing needs to serve it — which is also why you will never see an install command for it on this site.

No to both, and both are worth being plain about. It is a Pro feature, still in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build at all. And it is one live page in your real browser at one breakpoint at a time — the breakpoint control resizes that single canvas rather than opening a wall of frames. If a multi-frame infinite canvas is what you are shopping for, this is not that. Everything else on this page — the .test hostname, trusted HTTPS, the dev server, the task board — is in the free, open-source app.