Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages-aliased/addons/src/webpack.ts`:
- Around line 1-5: Update the thrown Error message in the
'@unhead/addons/webpack' removal notice to be framework-agnostic: replace the
hard-coded example '`@unhead/vue/bundler`' in the Error string with a generic
phrasing like "your framework bundler entry (e.g.
`@unhead/{vue,react,svelte,solid-js}/bundler`)" or "your framework's bundler
entry" so users of React/Svelte/Solid aren't misled; edit the string inside the
throw new Error(...) expression in the file to reflect this wording change.

In `@packages/bundler/src/unplugin/framework.ts`:
- Around line 53-58: The code treats options.minify === true as an empty object
so MinifyTransform never gets added; update the minifyOpts assignment so a
boolean true enables both JS and CSS minification: replace minifyOpts = typeof
options.minify === 'object' ? options.minify : {} with logic that if
options.minify === true set minifyOpts = { js: true, css: true }, else if it's
an object use it, otherwise {} — then the existing guard (if (minifyOpts.js ||
minifyOpts.css)) will correctly push { instance: MinifyTransform, options: {
...common, ...minifyOpts } } into defs.
- Around line 110-147: UnheadFrameworkOptions currently exposes validate and
devtools but those options are only honored in the .vite() branch (see
CreateHeadTransform injection of ValidatePlugin and unheadDevtools usage), so
update the type definition for UnheadFrameworkOptions to either remove validate
(if you want it unavailable outside Vite) or add explicit JSDoc noting that
validate and devtools are Vite-only and will be ignored by .webpack(),
.rspack(), and .rollup(); ensure the JSDoc mentions the related symbols
(CreateHeadTransform, ValidatePlugin, unheadDevtools) and that only .vite()
consumes these options so callers aren’t misled.

In `@packages/react/test/unified-plugin.test.ts`:
- Around line 25-29: The test currently only checks for any plugin with an apply
function but must assert the actual streaming plugin is present; update the test
in unified-plugin.test.ts (the Unhead({ streaming: true }).webpack() call) to
search the returned plugins array for a streaming-specific marker instead of a
generic apply check — for example look for a unique identifier on the plugin
such as its constructor name ("UnheadStreamingPlugin"), a public name property
(plugin.name === "UnheadStreamingPlugin"), or a dedicated flag (e.g.
plugin.__unheadStreaming) and assert that such a plugin exists; this ensures the
streaming webpack plugin introduced by
createFrameworkPlugin/Unhead(...).webpack() is actually included when streaming:
true.

In `@packages/vue/src/vite.ts`:
- Around line 11-16: Update the `@example` to reflect that Unhead now returns
Plugin[]: change the example usage of Unhead in vite integration so it spreads
the returned array into the plugins array (matching the bundler.ts and migration
docs) or remove the example; specifically update the example line that currently
shows plugins: [Unhead({ streaming: true })] to use the spread form plugins:
[...Unhead({ streaming: true })] (referencing the Unhead function and the
Plugin[] return shape).

---

Nitpick comments:
In `@packages/solid-js/src/bundler.ts`:
- Around line 8-17: Update the docstring in the unified bundler plugin factory
for `@unhead/solid-js` to include the Nuxt Kit forwarding path similar to the
Vue entry: add a small example showing addBuildPlugin(Unhead({ streaming: true
})) alongside the existing Vite usage (reference the Unhead factory exported in
this file and the addBuildPlugin call) so the docs mention both direct Vite
usage and the Nuxt Kit addBuildPlugin forwarding path.

In `@packages/svelte/src/bundler.ts`:
- Around line 8-15: Add a JSDoc `@example` to the Unhead bundler export to match
Vue/React parity: update the comment above the Unhead constant (created via
createFrameworkPlugin and typed as UnheadSvelteStreamingOptions, using
unheadSvelteStreamingPlugin) to include an example like calling Unhead({
streaming: true }).vite() so the public API usage is discoverable and consistent
across frameworks.

In `@packages/unhead/src/stream/unplugin.ts`:
- Around line 282-289: The comment above the createStreamingPlugin factory is
Vue-specific; update the docstring to a framework-agnostic example so it doesn't
single out Vue. Edit the block that references
createStreamingPlugin/createUnplugin (and related symbols StreamingPluginOptions
and buildStreamingPluginOptions) to replace "`@unhead/vue/bundler`" with a
neutral example such as "`@unhead/{vue,react,svelte,solid-js}/bundler`" or a
generic "the unified framework bundler entry" phrasing so all framework
consumers are equally represented.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/bundler/src/unplugin/framework.ts`:
- Around line 145-162: UnheadBundlerFactory.rollup currently calls
dispatch('rollup', defs) and then SSRStaticReplace.rollup({}) which leaves
SSRStaticReplace's internal ssr flag at its default false; update the rollup
path so SSRStaticReplace receives the correct SSR signal by either (A) plumbing
an explicit ssr option through dispatch/defs and passing it into
SSRStaticReplace.rollup({ ssr }) or (B) implementing a rollup-specific hook
inside SSRStaticReplace that inspects rollup build options (e.g.,
options.output.format or other env hints) to set ssr, and ensure
streamingPlugin.rollup(streamOpts) remains unchanged; if rollup SSR cannot be
supported, add a clear JSDoc note on UnheadBundlerFactory.rollup documenting
that SSR is not supported.
- Around line 138-162: The streaming plugin results are pushed directly
(streamingPlugin.vite/webpack/rspack/rollup) which can produce either a single
plugin or an array; mirror the dispatch() handling by normalizing before
pushing: call the streamingPlugin.* method, then if the result is an array
spread it into plugins, otherwise if truthy push the single item. Apply this
normalization to the vite, webpack, rspack and rollup branches so plugins stays
flat (instead of changing FrameworkPluginConfig.streamingPlugin types).

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@packages/bundler/src/unplugin/framework.ts`:
- Around line 58-95: Make CoreDef and related functions generic so you preserve
each plugin's option and return types instead of using any: change CoreDef to
parameterize the options/instance types (e.g., CoreDef<O, R> with instance:
UnpluginInstance<O, false> and options: O), update resolveCoreDefs to return
CoreDef<...>[] where the concrete option types come from the specific instances
you construct (TreeshakeServerComposables, UseSeoMetaTransform,
MinifyTransform), and update dispatch to infer the bundler-specific plugin
factory signature from UnpluginInstance so you can call
instance[bundler](options) without casting to any and return the correct
aggregated array type; this removes the (opts: any) => any cast while keeping
runtime behavior unchanged and preserves per-plugin type safety.