Framework Laravel Package

Product Decisions This Supports

• Build vs. buy, revisited at the module level. This release turns Pollora from a monolith into a framework that consumes four focused packages (pollora/block-bindings, pollora/roles, pollora/meta, pollora/assets) plus pollora/query. That is a signal for roadmap planning: capabilities like typed meta or roles & capabilities can now be evaluated, prototyped, or adopted independently of the full framework rather than as an all-or-nothing platform bet.
• Expanding beyond Laravel-only roadmaps. The extracted packages explicitly work without Laravel — the asset package resolves Vite builds for a classic theme, a plugin, or a Bedrock site. That unlocks a new addressable audience (WordPress agencies on Bedrock, plugin authors) and is worth a positioning decision: is Pollora a Laravel framework, or a set of WordPress packages with a Laravel integration layer?
• Feature parity with the block editor. Block Bindings now ships as a self-contained capability with its resolver, source registry, four built-in sources (post meta, term meta, author meta, options), editor script, and preview route. For a PM this is a shippable, demoable feature story: editors bind block attributes to data without custom code, and the preview route makes that evaluable in a sales demo.
• Deprecation and migration planning. Class names do not change and rendered output, REST responses, and command output are stated as unchanged — so this is an internal restructuring with an external contract of "no visible change." That is the cheapest possible refactor to communicate, and it should be treated as a stability release in the roadmap, not a feature release.
• Operational tooling as a product surface. pollora:doctor checks persist across all four domains, alongside pollora:binding:list, pollora:make:binding, pollora:roles:*, and pollora:meta:*. The latest patch adds a doctor warning for an APP_URL without a scheme and a Site Health check that flags a web server serving .env directly — a security posture item you can cite in procurement or audits. These are onboarding and support-cost levers — worth tracking as a metric (time-to-first-working-site, support tickets deflected).
• Testability as a product quality lever. Container resolution was replaced with explicit constructor arguments and small contracts (MethodInvokerInterface, BindingEventsInterface, PostFinderInterface, ViteManagerFactory, RuntimeContext, PublicPath). Fewer hidden container lookups means fewer flaky tests and easier contribution — relevant if the roadmap depends on community PRs or third-party extensions.
• Query API maturity. Accepting pollora/query 2.0 brings coverage of every WordPress query class, terminal methods (first(), ids(), count(), exists()), and per-builder docs. For product planning, that means fewer raw WP_Query escape hatches in feature specs and a simpler story for "how do we list/filter/paginate this content type."

When to Consider This Package

Adopt or upgrade when:

• You are building a Laravel application that must own WordPress content, roles, and meta — and you want those concerns as composable, individually versioned modules rather than a single framework dependency.
• You need typed meta with schemas, validation, and admin UI drivers, or roles and capabilities mapped to post types, and you want to consume only that slice.
• You ship classic themes, plugins, or Bedrock sites and want the asset/Vite pipeline without adopting the whole Laravel framework — the asset package now stands alone.
• You are already on Pollora: this release is a low-risk upgrade for application code (class names unchanged, output unchanged) but a non-trivial upgrade for your dependency graph (four new required packages, plus a pollora/query major).
• You want to test domain logic without booting Laravel — the PSR-11/contract-based refactor is a direct win for CI speed and unit-test coverage.
• You rely on Valet or Herd for local development — this patch fixes redirect loops on the home page and 404s on /cms/wp-admin/ that previously made those environments unusable out of the box.

Look elsewhere or defer when:

• You cannot tolerate query result changes. pollora/query 2.0 fixes semantics that previously ran: where() followed by orWhere() now groups earlier clauses as (a AND b) OR c, DateQuery::inclusive() actually takes effect, dates use a 24-hour clock, and invalid fields(), userPermission(), or orderBy() directions now throw QueryException instead of being silently ignored. Any production query relying on the old ungrouped or lenient behaviour will change results or start throwing. Pin pollora/query to ^1.0 and schedule a migration window with regression tests before letting composer update take 2.0.
• You need long-term API stability guarantees. A package split of this size means four new release cadences, four changelogs, and four sets of version constraints to keep aligned — reasonable for a team with dependency hygiene, painful for a team that upgrades twice a year.
• Your team is small and support surface matters more than modularity. More packages means more places to look when something breaks, even if the framework's own commands and doctor checks soften that.
• You need documentation maturity before committing. Extracted packages typically trail the monolith in docs; verify each package's README and upgrade guide (the pollora/query upgrading guide is a good indicator of the standard) before standardising.
• You depend on WordPress-facing behaviour being byte-identical in edge cases (hot-reload HTML, admin notices for missing builds). The release states rendered output is unchanged in build and hot mode — verify this in your own environment rather than assuming it.

How to Pitch It (Stakeholders)

For executives: This release is an architecture investment, not a feature bet. Pollora has been decomposed into four independent, reusable packages — block bindings, roles and capabilities, typed meta, and assets — each of which now works with or without Laravel. Application code does not change: class names, rendered pages, REST responses, and command output are all unchanged. The strategic upside is reach (the asset and meta packages can serve classic themes, plugins, and Bedrock sites, broadening the addressable market beyond Laravel shops) and maintainability (smaller, independently testable units with explicit contracts instead of hidden container lookups). The latest patch also hardens local development and security checks: it fixes Valet/Herd compatibility and adds a Site Health warning if .env is web-accessible. The one item requiring active management is the optional pollora/query 2.0 adoption, which corrects query semantics and will change results for a small set of existing queries — we recommend pinning to 1.x until regression tests pass.

For engineering: The runtime behaviour you ship is unchanged; the dependency graph is not. Be aware of four points. First, four new required packages now carry classes that previously lived in-tree — expect to align versions and re-read the changelogs, but no import or namespace edits are needed in application code. Second, pollora/query accepts ^1.0 || ^2.0; composer update will take 2.0, and 2.0 changes real query outcomes — where()/orWhere() grouping, DateQuery::inclusive(), 24-hour date handling, and hard QueryExceptions where invalid arguments were previously ignored. Pin ^1.0 in the root composer.json if you need time. Third, the Laravel-specific pieces stayed behind under Pollora\*\Infrastructure\Laravel (service providers, LaravelMetaValidator, LaravelMethodInvoker, LaravelBindingEvents, LaravelPostFinder, ViteManager, middleware, directives, and the artisan commands), so the framework still owns facades, validation, containers, and DX while the packages stay framework-agnostic — a clean seam if we ever need to swap a component. Fourth, the constructor-injection refactor (AssetEnqueuer, AssetFile::resolveUsing(), AssetManager, MetaUiDrivers, MetaAccessor::extend()) makes unit testing materially easier and removes container teardown hazards in tests; it is safe to lean on in new test suites. The latest patch additionally fixes APP_URL scheme handling, Valet/Herd front-controller detection, and /cms/wp-admin/ routing, plus adds a Site Health check for exposed .env — all low-risk fixes.