v0.0.149

• Adopt Next.js-style icon file conventions: drop icon.png, icon-dark.png, and apple-icon.png next to config.json at the project root and Doccupine copies them into the generated site's public/ and wires them through a generated icons.json and a new utils/icons.ts into the site metadata, every URL carrying a content-hash query so a replaced icon busts browser caches. The dark variant is emitted as prefers-color-scheme media entries and apple-icon.png becomes the apple touch icon, with favicon.ico in public/ remaining as the legacy fallback path. Precedence is: a page's frontmatter icon wins on that page, then the root icon files, then config.json's icon, then the built-in default - and an icon-dark.png without an icon.png beside it warns and is skipped, since there is no light icon to pair it against. A root icon file and a same-named file in your own public/ directory would publish the same URL, so copying either now fails - checked in both directions - instead of one silently overwriting the other; a symlinked icon source is rejected before any output is touched, the files are watched in watch mode so adding, replacing, or deleting one resyncs the site live, and the copies are tracked in the artifact manifest so a removed icon is pruned like any other generated file. Regression coverage grows to 326 tests
• Paint the browser chrome - the iOS Safari status bar, say - in the site's own brand color from the first frame: the theme-color meta was synced from OS-scheme-scoped colors after hydration, which disagrees with the site's cookie-based mode, so a dark site visited on a light-OS device showed the wrong chrome until the theme provider took over, a visible flash on every load. The blocking pre-paint script that already resolves the theme cookie before first paint now writes meta[name="theme-color"] from that same resolution, with each mode's primary color interpolated at app build time, and the post-hydration sync moves to cherry-styled-components 0.2.15's $themeColor handling, which resolves the primary token through computed styles to the same per-mode hex - so the chrome color never jumps at hydration. app/theme.ts drops "use client" so the layout template can read the palettes server-side, and ThemeModeAttribute now mirrors data-theme from the theme cookie rather than counting effect passes: the old skip-the-first-run ref guard broke under React StrictMode's development double-invoke, where the second pass fired before the provider had reconciled the server-rendered light theme and flashed dark loads white, and the pass-counting path survives only as a fallback for cookie-blocking browsers
• Fill the docs sidebar so it reads as a panel rather than a barely-there tint: the desktop navigation sidebar and its sticky footer used a 5% primaryLight wash over transparent; both now mix 8% primaryLight into the opaque page background through color-mix, and the sticky footer's now-pointless backdrop blur is removed along with the dead declarations it was masking. The right table-of-contents rail keeps its plain page background
• Document the new surface area in the generated starter documentation: Global Settings gains an "Icon files" section covering the three root icon files, their precedence over config.json's icon field, and the collision error against public/; Media and assets points its favicon guidance at the icon file convention, keeping favicon.ico documented as the legacy fallback; Theme notes that the browser-chrome color now derives from each mode's primary token; and Commands gains a "Browsing from another device" section explaining ALLOWED_DEV_ORIGINS for pages opened over a LAN IP or a Tailscale hostname, which otherwise render but never become interactive
• Update dependencies: the CLI moves @readme/openapi-parser to ^7.0.0, and generated apps move to cherry-styled-components ^0.2.15, styled-components ^6.5.0, posthog-js ^1.411.0, and posthog-node ^5.47.10