Bi Laravel Package

Technical Evaluation

Scope boundary — read this first. luminix/bi is a dashboard manager, not a Business Intelligence engine. It provides the dashboard abstraction (resolution, layout, block/widget registration, boot payload wiring), not the semantic layer, query planner, warehouse connectors, caching strategy, or charting library. Any business case that assumes "we install this instead of Metabase/Looker" is mis-scoped; the value is that dashboard definitions become first-class PHP/Laravel artifacts living in app/Bi/Dashboards alongside the rest of the app. A TPM must locate the metric/query layer explicitly before committing — it lives outside this package.

Architecture fit. Tightly idiomatic Laravel: a service provider registers routes, config and reducers; dashboards are resolved by convention from app/Bi/Dashboards; consuming apps publish assets and a machine-readable skill (vendor:publish --tag=luminix-skill). The coupling to luminix/frontend is the defining architectural fact — reducers are registered into that package's BootService static registry during boot, and DashboardResolver is now constructed on every boot payload, not only on BI routes. That makes this package a global participant in the host application's request lifecycle rather than an isolated module. Fit is excellent for a Lumix-based Laravel monolith; it is an awkward graft onto an app that does not already run luminix/frontend.

Integration feasibility. Low friction mechanically: composer require, publish config/tags, define dashboard classes, done. The real work is authoring block classes and wiring data sources, which is application code, not package configuration. Absence of a workbench means package-level behaviour is validated through orchestra/testbench throwaway Laravel instances — fine for the vendor, but it means consumers get no reference host app to copy from beyond what the skill file describes.

Technical risk.

• Global blast radius. The docs are explicit that DashboardResolver is built on every boot payload and "must be cheap and incapable of throwing, or every page of an app without app/Bi/Dashboards breaks." A BI module that can take down unrelated pages is a top-tier review item.
• Static mutable state. BootService's static reducer registry requires flushReducers() in test teardown to avoid cross-test leakage. Static registries are a well-known hazard under long-running workers (Octane, queues); no compatibility evidence is provided.
• Release engineering. Versions are derived from commit subject tokens ((MAJOR)/(MINOR)), and every green push to v1.x auto-tags. That is fast but removes a human release gate, and the empty tag_prefix is inconsistent with pre-existing v1.1.x tags — a future archaeology problem.
• Metadata anomalies. A last-release date in 2026 and origin/HEAD still pointing at v0.x while v1.x is the release branch. Both need verification before any dependency is pinned.
• Zero adoption signal. 0 stars, 0 dependents, single-org provenance. There is no third-party evidence of production use, no issue history to mine, and no ecosystem pressure to keep the API stable.

Key questions for the maintainer:

1. Where do metric definitions and queries live, and what are the performance characteristics at 10k–1M row cardinality?
2. Does dashboard/widget resolution honour Laravel authorization gates and multi-tenancy scoping?
3. Is the static reducer registry safe under Octane, and is that covered by the CI matrix?
4. What is the support commitment and intended lifespan of v1.x?
5. Can DashboardResolver be made opt-in/lazy so non-BI routes pay nothing?
6. Is the 2026 release timestamp real, and which tag should a new consumer pin?

Integration Approach

Stack fit. Requires PHP 8.2–8.5 and Laravel 11–13, and transitively luminix/frontend. It is a fit only if the host app already consumes the Lumix frontend stack; otherwise budget for adopting two packages and their asset pipeline at once. For apps on Livewire/Inertia/Vue-without-Lumix, the integration cost is materially higher than the README implies.

Migration path. Treat this as a re-homing exercise, not a lift-and-shift. Dashboards built as Blade views, Nova cards, or embedded Metabase/Power BI iframes are re-authored as dashboard + block classes; the queries behind them must be ported to whatever data layer you supply. Recommended path: (1) pick one low-risk internal dashboard, (2) port it behind a feature flag, (3) run it in parallel with the incumbent for two weeks comparing numbers, (4) only then expand. Never migrate the executive-facing dashboard first.

Compatibility. Two version axes must be pinned together: this package and luminix/frontend. Add a Composer constraint on both and let the 10-job CI matrix (PHP × Laravel) inform your own CI matrix rather than replace it. Verify the published skill/ copy matches the pinned version — the docs state fixes reach consumers only on the next vendor:publish --force, so skill drift after an upgrade is a real failure mode.

Sequencing.

1. Spike in a throwaway branch: install, publish, define one block, confirm boot payload renders.
2. Measure dashboard-resolution overhead on a non-BI route before and after (this is the go/no-go gate).
3. Confirm Octane/queue-worker behaviour or formally document the incompatibility.
4. Establish a data-layer contract (interface + caching) before authoring more than one dashboard.
5. Add a contract test in your suite that asserts / still boots when app/Bi/Dashboards is empty or malformed.

Operational Impact

Maintenance. Bus factor is the headline risk: single-organisation provenance, 0 dependents, 0 stars, no external contributors. Human-facing documentation ships in Portuguese only, which is fine if the team is Portuguese-speaking and a genuine onboarding tax if not — the English skill/ file covers agent consumption, not human tutorials. Budget for a named internal owner who reads src/ rather than documentation. The package's own hygiene is above average (multi-version CI, automated releases, explicit .gitattributes shipping rules, documented test commands), which partially offsets the adoption risk but does not remove it.

Support. No SLA, no issue-tracker history to assess responsiveness, no security-disclosure process in evidence. For an internal analytics surface this is tolerable; for anything customer-facing or regulated, treat it as unsupported software and plan to vendor-fork.

Scaling. Unknown and unmeasured in the supplied material. Two distinct scaling questions: (a) request scaling — the per-boot DashboardResolver construction adds cost to every page, so it degrades the whole app, not just BI; (b) query scaling — entirely dependent on the data layer you build behind the blocks, so profiling effort belongs there. The SQLite-only test strategy means DB-specific behaviour on MySQL/Postgres is unvalidated.

Failure modes.

• DashboardResolver throwing or being slow → every route in the host app degrades or 500s. Highest-severity, lowest-visibility failure.
• Static reducer registry leaking across long-lived workers → cross-request state contamination under Octane.
• Skill doc drifting from the pinned release after --force skip → agents and developers following stale API guidance.
• Semver-by-commit-subject misfire → a breaking change shipped as a patch; consumers with caret constraints silently break.
• Upstream luminix/frontend incompatibility → both packages must move together; no independent upgrade path.

Ramp-up. Expect ~1–2 days for a Laravel-fluent developer to author a first dashboard, plus 2–3 days to design the data-layer contract, and a further 1–2 days of environment setup for teams not already running Docker-based PHP (there is no local PHP path — everything runs through the php-composer:8.3-imagick image). Agent-assisted development via the shipped skill/ meaningfully shortens the API-learning curve, provided the skill version matches the installed tag. Net: a small, competent team can be productive in a week; the residual risk is not learning curve but longevity.