` drops containment | | a stylesheet from the header shows on the live site but not in the editor canvas | the canvas loads only the layout's `` | move site-wide CSS into the layout folder (`transfer.mjs ./theme --theme `) | | the header does not stick | either the block sets `props.overflow: "clip"` (a clipping ancestor defeats sticky), or you asked for stickiness inside your own markup instead of on the block | `vz-sticky` on the root node, or `props.position: "sticky"`; drop any `position: fixed` spacer — that workaround is obsolete since 2026-08-19 | | a **platform** `siteHeader`/`siteMenu`/`siteFooter` ignores `props.position` | those kinds draw their own band; the block wrapper never runs for them | `siteHeader` has its own `props.sticky: true`; the other two have none — own markup in the kit instead | | a block sticks on the live site but not in the editor preview | the editor canvas does not ask the wrapper for stickiness | check on the shop URL. Nothing to fix | | your own class on a block is missing from `class=` | names are validated whole and dropped whole: max 3, `^[a-zA-Z_][a-zA-Z0-9_-]*$`, nothing starting with `vz-` | rename it; see `vizen-own-markup` §4 | | you set `props.wrapperClass` and your CSS does nothing | the CSS is in a **level 1** document, so it is inside a shadow root and cannot see the wrapper | move that stylesheet into a **level 3** document | | deleting fails with `invalid request body` | `DELETE` needs a body | send `{}` | | ~~an image URL 404s on `HEAD`~~ | **closed since 2026-08-20** — the resizer answers `HEAD` and `GET` alike; `HEAD` is a fine way to check that an image URL resolves | — | | two product cards on one page | a bound `layout` block plus the resource's own bundled card | see `vizen-chrome`, card replacement | | a **level-1** widget renders without the site's fonts and colours | it used to: a shadow root isolates in both directions, so the layout's stylesheets never crossed it. Since 2026-09-13 they are put inside the shadow root and your markup is wrapped there in `.vz-theme-{doc}` — the theme applies, and your own rules still win. Still bare? the page has no layout at all, or the rule is compound (`body.dark`), which is never rescoped | bind a layout (`vizen-chrome` §2a), or move that class onto your own root element | | a level-2 menu panel opens only after a short pause | **not a bug.** The server prints the panels into the HTML within a node budget (60 nodes); a root that did not fit loads its panel on the first click from `GET /categories?view=menu` — one request per tab | nothing to fix. Your own header is unaffected: the budget belongs to the platform `siteMenu` | | your CSS styles the header and nothing else on the page | a **level-1** header keeps its CSS inside its shadow root (a level-3 header's stylesheet reaches the whole page — but not the editor canvas) | move it into the **layout's folder**, where it lands on every page and in the canvas: `vizen-own-markup` §6.2 | | a style, font or `` tag appears on one page only | it was uploaded as a page widget instead of the layout folder | same fix — `transfer.mjs ./theme --theme ` | | layout styles apply but the layout's script never runs | you are on `/cart`, `/checkout`, `/account`, `/wishlist`, `/orders`, `/deals` or `/dashboard` — author code is not executed in the guarded zones by design | nothing to fix; do not plan scripted behaviour there | | your script worked on a direct hit and stopped after an in-site click | navigation is soft; the code ran once on load | re-init on `document`'s `vz:navigate` event (`detail.path`), not on `DOMContentLoaded` | | `body {}` / `:root {}` from the layout folder did not apply | the selector was compound (`body.dark`, `body[data-x]`) — only bare `html`/`body`/`:root` are scoped onto the page root | put that class on your own root element, or use the bare selector | | `PUT /html-documents/{id}` on a layout's folder answers `THEME_DOCUMENT_PROTECTED` | the folder's document is a service row; it is changed through releases only | `POST /themes/{id}/site/releases` → PUT bytes → `…/publish` | Something silently ignored that is not listed here belongs in the area document — `backend-3D/docs/api-areas/` — as a named case. ## 3. Acceptance checklist Run all of it before telling the owner you are done. - [ ] the pages you did **not** touch look unchanged — check the home page and two sections; - [ ] the page opens by direct URL **and** by clicking a link inside the site — these are different code paths, and scripts behave differently; - [ ] after an in-site click: dropdowns open, modals open, timers run; - [ ] the header holds at several widths, not just yours; - [ ] no horizontal scrolling on the page body; - [ ] the cart really accepts an item — press the button, watch the counter; - [ ] the text is present in the raw HTML (`curl` and grep for it), otherwise search engines will not see it; - [ ] images are served through the resizer, not as originals; - [ ] the owner is told plainly what is a workaround and what is not. ## 4. Measuring, not guessing Install a browser in the scratchpad and drive it. Status codes cannot tell you whether a dropdown opens or a header sticks. One run spent 18% of its steps on this, and it was the cheapest 18% in the whole build — every finding that survived came from a measurement, and the one finding that did not survive came from reading code instead. ## HTML widget (folder / release) — what "nothing changed" usually means - **`PUT /html-documents/{id}` answers `HTML_PROJECT_USE_RELEASE`.** The document has an active release: change it only through a release (`POST …/releases` with `base:"active"` + the changed files → PUT bytes → `POST …/releases/{rid}/publish`). Name/description still go through PUT. - **Files 404 on the site right after publish.** Look at the page source: the asset root must be the NEW release (`/_html/{doc}/{rid}/`). Only the active release is served; old rids answer 404 by design. Hard-reload the page (the html is not cached, the files are immutable per rid). - **Second widget on the same page breaks the first one's images.** The script used the global `window.VZ_ASSET_BASE`, which the last widget overwrites. Read the root from the wrapper instead: `document.currentScript?.closest('.vz-body')?.dataset.vzBase` (inline) or `document.querySelector('.vz-body-')?.dataset.vzBase` (external/defer). - **`:root`/`body` styles apply on the site but not in your local file, or vice versa.** On the site they are rewritten to `.vz-body-{doc}` (both inline `