Tailwind CSS v4 auto-detection scoping uncertainty in monorepo builds

Tailwind CSS v4 replaces the v3 content array with CSS-first configuration and relies on automatic content detection to scan for template files. In a monorepo or workspace, the goal is a repeatable build where the same source tree always produces identical utility output on every machine.

The unresolved behavior is whether the built-in heuristics reliably cover packages outside the scanned root, and whether coupling to .gitignore means a missing or divergent ignore file can silently change which classes are generated. Explicit @source directives, @source inline(...), and @source none offer deterministic control, but they require maintenance whenever source directories move and change how dynamic class names are specified compared to the v3 safelist.

Should teams trust auto-detection for multi-package repositories, pin explicit @source globs, or disable detection entirely with @source none for locked-down CI? How can generated CSS be audited to confirm every workspace package is included without relying on implementation-defined scanning behavior? Does the documented migration from safelist to @source inline(...) add maintenance overhead that affects build repeatability?