Filament Gatekeeper Laravel Package

Technical Evaluation

Architecture fit. LaraArabDev/filament-gatekeeper is a Filament panel plugin, so it sits in the presentation/authorization layer of a Laravel application rather than in domain services. The v1.1.5 headline change — "deduplicate field/column discovery" — confirms the core mechanism is reflective auto-discovery: the package walks Filament form/table schema components and derives policy targets (fields and columns) from them. That is an architecturally sound pattern for Filament (it mirrors how Filament itself resolves components), and it keeps per-resource boilerplate low. The trade-off is that the package's correctness is coupled to Filament's internal schema APIs, not to a contract we control.

Integration feasibility. Standard Composer install plus plugin registration in the PanelProvider. The risk surface is typical for Filament plugins: publish config, possibly a migration for permission/rule storage, and wiring into the existing authorization stack (likely spatie/laravel-permission or Filament Shield). No evidence in the release notes of new configuration keys or schema changes in v1.1.5, which keeps the integration cheap. The README rewrite with full auto-discovery documentation is materially useful — it is the artifact that lets an engineer determine what the package infers before trusting it.

Technical risk.

• Convention coupling. Auto-discovery means the package's behavior is a function of how resources declare their schemas. A resource using a custom component, a dynamic/repeater field, or a macro-built column may be discovered differently or not at all. Deduplication being fixed in a patch release implies the discovery pass could previously register the same target twice — a class of bug that recurs whenever discovery logic is heuristic.
• Silent under-enforcement. This is the dominant risk. If a field is missed by discovery, the failure mode is granting access, not denying it. That is a security regression, not a UX bug, and it will not surface in smoke tests.
• Bus-factor and maturity. Single-maintainer OSS at 1.1.5. The CI fix in this release (grep instead of bash regex) is a positive maintenance signal but also evidence the pipeline is still being hardened.
• Version matrix. Filament moves fast across majors; a 1.x plugin usually pins a narrow Filament range.

Key questions.

1. Which Filament major versions and PHP/Laravel versions are in the declared support matrix, and is that matrix enforced in CI?
2. Is enforcement default-deny (undiscovered = hidden) or default-allow (undiscovered = visible)? This single answer drives the entire risk posture.
3. Is discovery resolved at runtime per request, or cached/compiled? What is the invalidation trigger on deploy?
4. Does it integrate with an existing permission backend, or does it own its own persistence layer?
5. What is test coverage on the discovery pass, and are there fixtures for custom/dynamic components?
6. How are multi-tenancy and super-admin bypass handled?
7. Behavioral change between 1.1.4 and 1.1.5 for anyone already relying on the duplicate-registration behavior?

Integration Approach

Stack fit. Well-suited to a Laravel + Filament admin panel that already has, or is about to build, role-based access control with per-field granularity. Poorly suited to a team that wants explicit, declarative authorization — auto-discovery trades auditability for ergonomics, and teams with compliance review requirements will find "the package inferred this" an uncomfortable answer.

Migration path. Greenfield adoption is straightforward: install, publish config, register the plugin, seed the permission set, verify. For an existing panel already using policies or Filament Shield, the sequencing matters — run the package in shadow mode first if it supports it, otherwise inventory what it discovers and diff that against your current policy coverage before enabling enforcement. Do not run two authorization layers in enforcement mode simultaneously.

Compatibility. Pin both the Filament minor and the plugin minor in composer.json. Because the plugin reads Filament internals, a Filament patch release is a potential breaking change for this package even though it is not one for Filament. Treat Filament upgrades as requiring a plugin regression pass.

Sequencing.

1. Spike in a scratch environment against a copy of the real panel — not a toy resource. Discovery heuristics need representative schema complexity (nested layouts, repeaters, custom fields) to be meaningfully tested.
2. Build a discovery diff report: every form field and table column in the app, versus what the package reports it will gate. Review that list manually. This is the highest-value hour of the entire engagement.
3. Add CI guard asserting the discovered-target count doesn't drop between commits — catches regressions when someone adds a resource or bumps Filament.
4. Pilot on one non-critical resource, then one sensitive resource, then broad rollout.
5. Document the fork/patch path before rollout, not after.

Operational Impact

Maintenance. Low ongoing effort if the version matrix stays narrow and Filament upgrades are batched. The real maintenance cost is the re-verification ritual on every Filament bump and every new resource type. Budget for both. Single-maintainer dependency means we should be prepared to vendor the package; confirm the license permits it before adopting.

Support. Community-only, no SLA. Acceptable for an internal admin panel, not acceptable for anything customer-facing or audited. Escalation path is "read the source" — which is feasible here given the package's scope.

Scaling. Two dimensions. Schema scale: auto-discovery over a large panel (hundreds of resources) is a per-request cost unless results are cached; confirm caching exists and is keyed appropriately (Filament version + resource class + schema hash). Data scale: per-field authorization checks in tables risk an N+1 pattern if each cell resolves permissions independently — verify there's per-request memoization, especially on paginated tables.

Failure modes.

• Over-permission via missed discovery — highest severity, lowest observability. Mitigate with the CI target-count guard and periodic manual audit.
• Over-restriction via duplicate/mis-keyed discovery — the bug fixed in 1.1.5 suggests this was real; users see missing fields and file support tickets, so it's noisy but not dangerous. Note that the fix's absence in 1.1.4 means anyone on ≤1.1.4 should upgrade.
• Filament upgrade breakage — discovery returns empty or partial; combined with default-allow semantics this becomes a security incident.
• Cache staleness after deploy — stale discovery map gates the wrong fields until cleared. Ensure cache invalidation is part of the deploy checklist.

Ramp-up. Low for anyone already fluent in Filament — the mental model is "policies, but inferred from schema." The rewritten README in this release materially reduces the time-to-first-successful-integration and is the main reason this release is worth adopting over 1.1.4. Expect roughly half a day for a competent Laravel engineer to reach a working pilot, plus the discovery-diff review, which is where the actual effort lives. No new concepts to teach the team beyond the deny-by-default question, which should be answered in writing before rollout.