The passThroughStreamAligned function treats nil and false as different values. In the context of LLM requests, a nil stream parameter is semantically equivalent to false. If an outbound transformer explicitly sets stream: false in the request body (which some do for explicitness) while the original request had it as nil, pass-through will be unnecessarily disabled. Consider treating nil and false as equivalent.

func passThroughStreamAligned(originalStream, effectiveStream *bool) bool {
	isTrue := func(b *bool) bool {
		return b != nil && *b
	}
	return isTrue(originalStream) == isTrue(effectiveStream)
}

The autoAggregateStream method bypasses the structured llm.Response phase by calling Inbound.AggregateStreamChunks directly to get the final body. This causes all OutboundLlmResponse middlewares (applied via applyLlmResponseMiddlewares) to be skipped for auto-aggregated responses. If there are middlewares performing critical tasks like content filtering, PII redaction, or structured validation on the llm.Response object, they will not run in this fallback path.

Checked this path carefully.

The auto-aggregate fallback does not skip the whole middleware chain. It still runs the full streaming path through p.stream(...), which means the stream-phase hooks are already applied before aggregation:

• raw stream middlewares
• Outbound.TransformStream(...)
• OnOutboundLlmStream(...)
• Inbound.TransformStream(...)
• inbound raw stream middlewares

What it does not do is re-enter the separate non-stream OnOutboundLlmResponse(...) phase after the stream has already been transformed and consumed.

So this is not a full middleware bypass; it is specifically a response-phase gap after a path that already executed the stream-phase hooks.

Given the current architecture, I am leaving that out of this PR:

• stream-aware middleware already has OnOutboundLlmStream(...)
• auto-aggregate is implemented by draining the transformed stream and synthesizing the final HTTP response
• re-entering OnOutboundLlmResponse(...) would need a separate design for how to build a final *llm.Response from the drained stream path and how to avoid double-processing middleware that already handled the streaming phase

For this PR, the supported behavior is that the fallback path executes the streaming middleware phase, while any "also run response middleware after aggregation" change is treated as a separate follow-up design/task.