# Astro integration verification 18 October 2026. Linked to `REQ-PRODUCT-ASTRO`, `REQ-PRODUCT-CONSENT-RUNTIME`, `REQ-PRODUCT-SAFE-CONTENT` and `REQ-PRODUCT-MOBILE`. - The final `npm run check` passed 122 package tests and 13 site tests, catalog validation, the documentation/example build and a Worker dry run. A separate check of the running local Worker verified the interactive/static route policies; public build files contained neither the local host key nor its Basic authorization encoding. No remote deployment or package publication was performed. - The example compiles with the installed Astro 7.4.0 toolchain. Its privacy, cookie and terms routes contain the core's exact structured legal articles and no scripts or inline styles. The interactive pages use external self-hosted modules and a route-specific script/connect policy. Generated public inputs and outputs have explicit path allowlists; an unmanaged input fails before compilation. - Packed-consumer tests install the actual core tarball in a separate project. The default installation brings neither Astro nor React. The consumer then uses the repository's pinned Astro compiler to compile components from the installed tarball, including escaped content, production draft rejection and explicit preview mode. This verifies package contents and framework compilation; it does not simulate a fresh network installation of the entire framework toolchain. - DOM tests exercise one bridge per controller/document, duplicate surfaces, repeated page-load events, destroyed controllers, setup failure cleanup, routes without a surface and eventual host cleanup. Before-swap closes an unsaved draft without persisting its selections; page-load remounts one controls surface while retaining the controller and existing service registrations. Dialog methods are simulated in these tests, so they do not establish visual or native-dialog behavior. - Real Chromium inspection used the actual locally served Worker assets. A saved granular choice recovered with Measurement active, Suggestions blocked and one initiated fictional request. Client navigation retained that state and one controls/dialog mount. Rejecting through the reopened drawer stopped Measurement, restored focus to the invoking Review button, and retained refusal on the next page without another request or notice. - A separate browser sequence began with both services blocked and zero initiated optional requests. Allowing only Measurement raised the count to one; withdrawal stopped it, and explicitly allowing it again raised the count to two. Navigating to the second page retained two rather than resetting or incrementing the counter, confirming that navigation reused the bootstrap and did not restart the active service. - At 390×844, settled document client/scroll widths both measured 375 CSS pixels. The deliberately opened native drawer occupied the bottom 633 pixels and focused its heading. At 320×568, client/scroll widths both measured 305 pixels; the drawer stayed within that width, with visible reachable actions and a separately scrollable body. Closing it left refusal unchanged and restored focus to the Review button. Browser viewport overrides were reset after inspection. - Following the privacy link left the interactive router through a full page navigation. The destination exposed the complete article, zero script elements, no router marker and no consent controls. Its narrow document client/scroll widths both measured 305 pixels. No page error logs were observed in these inspected flows. Screenshots: [mobile initial notice](), [opened mobile drawer](), [narrow drawer](), [retained lifecycle across navigation](). This is an initial Chromium and Astro 7 preview, not a complete accessibility or platform audit. Screen readers, zoom, RTL, other browsers and Astro versions still need review. A host must retain a working preferences surface on every client-routed page where optional services continue. The bridge does not stop services merely because a route omits its controls, govern unrelated scripts, or infer legal applicability. Rich Markdown/MDX artifacts use the authoring outputs described in the guide. ## Ordinary form permissions The real two-page permission example now shares the existing controller, named exact-offer field, session backend and recovery journal. Initial Chromium verified draft preservation without grant, local form submission without navigation, explicit recording, navigation and mobile withdrawal. The [form permission verification record]() records screenshots, regression coverage and remaining platform limits.