Matrix Choice Laravel Package

Product Decisions This Supports

• Build vs. buy for survey/assessment surfaces — buy. lara-zeus/matrix-choice is a Filament form field that renders a rows × columns grid with one selection per row. That is the exact shape of Likert scales, NPS/CSAT batteries, onboarding questionnaires, skills self-assessments, compliance checklists, and priority/comparison matrices. It is a commodity UI pattern: expensive to hand-roll, zero competitive differentiation. Adopting it converts a multi-week custom-UI build into days of configuration.
• Scoping the roadmap item. This is a bounded presentation-layer primitive — no migrations, no data-model lock-in, no service footprint. Validation, scoring, allow-lists, and persistence stay with us. That means the decision is cheap to make and cheap to reverse: we can commit a roadmap slot against it without a platform bet or an architecture review.
• Per-context option control (new in 5.0.1) is the one capability worth planning around. It lets us hide individual options per persona, plan, role, or row instead of maintaining a duplicate field definition per variant. Product consequences: suppressing "Not Applicable" where it's meaningless, gating options by entitlement, removing already-used options from repeated rows, and progressive-disclosure questionnaires — all without branching form logic. If our spec calls for any of that, 5.0.1 is the version to target.
• Feature definition hygiene. Because the component owns only rendering and cell state, we should define the feature in terms of the form schema (declarative, in one field class or config), not in terms of the plugin. This keeps any future swap or vendoring a contained change rather than a rewrite.
• Roadmap signal, not a platform commitment. Maintained 5.x line with small, regular, low-drama releases and clean CI hygiene. Safe to schedule a near-term item against; treat the package as replaceable.

When to Consider This Package

Adopt when:

• You are already on Filament. This is a Filament form field, not a generic Blade/Livewire component — there is no headless path. If the surface isn't a Filament form, the package does not apply and there is no workaround worth building.
• The interaction is genuinely rows × columns. Forcing a single "pick one of five" question into a matrix adds cognitive load and hurts completion rates — use a radio group instead.
• The alternative is a custom field on a near-term deadline. 5.0.1 is a low-risk, additive-only patch you can pin.
• You need option-level visibility rather than duplicating field definitions per persona or plan.

Look elsewhere / do not adopt when:

• You are not on Filament, or you're on a different Filament major. Plugin compatibility tracks the host framework's form API, so it will drive your upgrade calendar. Filament majors are the primary fault line.
• The matrix needs per-cell free text, nested follow-ups, or computed/scored output. That's layering business logic onto a presentation component — own the schema ourselves instead.
• The data feeds regulated scoring or audited reporting, where we need full control of rendering, allow-lists, and versioned behavior.
• You need strict SemVer guarantees or vendor support. A user-facing feature shipped in a patch release (5.0.1) is a governance smell: pin exact versions, read changelogs, don't assume patch = inert. One primary maintainer, ~27 stars, zero dependents, best-effort support, no SLA or LTS.

Release read for 5.0.1: effectively non-functional — docs restructuring plus three Dependabot bumps to CI tooling — with one additive, opt-in feature. No breaking changes, no deprecations, no migration. Safe to adopt; no urgency to adopt for it. 5.0.0 remains equally valid if we don't need option hiding.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can deliver the questionnaire/matrix-form item on our roadmap by adopting a small, actively maintained open-source Laravel/Filament component instead of commissioning custom UI work — turning a multi-week build into days of configuration and freeing engineering for the work that actually differentiates us. The latest release adds per-context option hiding, which is precisely the per-persona and "not applicable" behavior our spec calls for. Risk is contained: 5.0.1 carries no breaking changes or migration, the dependency is presentation-layer only so our data model isn't locked in, and we pin the exact version so upstream can't surprise us. Recommendation: adopt for the current roadmap item, fund a one-day spike to validate it against our form requirements, and keep the field definition thin so we can swap or vendor it if the plugin stalls. Note the support reality — one primary maintainer, best-effort, no SLA — which is acceptable for a form input and would not be for anything owning data or auth.

For engineering (talking points):

• Scope: a Filament form field, not a form engine. It owns rendering and cell state; we own validation rules, allow-lists, scoring, and persistence. Keep it a thin declarative layer — never the place business rules accumulate.
• Spike (½–1 day), on a non-critical form: install exact 5.0.1, render, select, validate, persist, and re-render a saved record. That is the entire integration risk envelope.
• Pin 5.0.1 exactly, not a caret range. This project ships features in patch releases, so read diffs before bumping. 5.0.0 → 5.0.1 needs no config, asset, or database work; 4.x → 5.x is the real migration boundary.
• Verify option-hiding semantics before relying on it: is "hidden" presentation-only or enforced server-side? Land a contract test asserting a tampered submission of a hidden option is rejected, plus a check that a persisted value referencing a now-hidden option still renders gracefully. This is the highest-value artifact the adoption should produce.
• Compatibility: confirm php / laravel/framework / filament/filament constraints in composer.json against our pins via composer why-not. Test Filament majors first on any upgrade.
• Isolate and cost the exit: keep the matrix schema in one field class/config, and estimate the vendoring cost now — it's our real mitigation for the single-maintainer risk, and it's feasible given the small surface.