Tameng Laravel Package

Product Decisions This Supports

• Build vs. buy for admin authorization: Tameng already provides the Filament-native permission layer (resources, pages, widgets, custom permissions, role policies). The 1.4.0 fixes make it more credible as a “buy/adopt” choice instead of building bespoke permission tooling around Filament shields.
• Multi-panel roadmap decisions: The corrected scoped_to_panel support across PermissionHelper, middleware, traits, tameng:check, and generated policies is a direct enabler for products that expose separate admin, partner, or customer panels with distinct permission namespaces. This reduces the risk of shipping panel-scoped RBAC as a later, high-cost refactor.
• Operational rollout and migration planning: The tameng:sync overhaul—now syncing pages, widgets, custom permissions, role policies, and resources—supports repeatable permission lifecycle management. That matters for release planning, environment promotion, and avoiding permission drift between code and database.
• Policy strategy: Policy lifecycle hooks (before/after) and panel-scoped handling in generated policies support decisions about centralizing authorization logic versus hand-writing policies per model. Teams can adopt generated policies with more confidence and customize around hooks.
• Quality and supportability decisions: The added Pest coverage for core permission helpers, plugin wiring, middleware, and traits is a signal for engineering due diligence. It does not replace a security review, but it lowers the adoption risk for teams that require automated regression coverage.
• Feature prioritization: The permission counter accumulation fix and super-admin install guidance fix are maintenance-quality improvements, not headline features. They should be treated as reliability work that reduces PM overhead around permission reporting and onboarding.

When to Consider This Package

Consider Tameng when:

• The product is built on Filament and needs an admin UI for roles, permissions, resources, pages, widgets, and generated policies.
• You operate or plan multiple Filament panels and need panel-scoped permissions to be respected consistently by helpers, middleware, traits, checks, and generated policies.
• You want command-driven permission synchronization (tameng:sync, tameng:generate, tameng:check, tameng:install, tameng:super-admin) rather than manually curating permission records.
• You need generated policy scaffolding with extension points (before/after) and are comfortable owning the resulting policy code.
• You value a package that now includes automated test coverage for its core authorization paths.

Look elsewhere or proceed cautiously when:

• The application is not Filament-based; the value proposition depends heavily on Filament resources, pages, widgets, and panels.
• You need enterprise-grade ABAC, external IdP integration, delegated administration, or audit/compliance workflows that go beyond role/permission management.
• You require a large, mature ecosystem, long-term maintainer history, or independent security certification; this release improves confidence but does not by itself prove those attributes.
• Your multi-tenancy model extends beyond Filament panels—for example, tenant-scoped permissions inside a single panel—and you need explicit support for that isolation model.
• You do not want generated policies or command-managed permission state; the package’s workflow may add more process than value.

How to Pitch It (Stakeholders)

For executives: Tameng is a Filament permission-management package that can reduce custom build effort for admin authorization. Release 1.4.0 fixes a permission-counting bug, corrects multi-panel scoping across the authorization stack, and expands tameng:sync so permissions and policies stay aligned with the application. It also adds Pest coverage for core permission behavior. Net: lower delivery risk for multi-panel admin products and less bespoke RBAC tooling to maintain.

For engineering: Treat 1.4.0 as a meaningful reliability release. The important changes are consistent panel-scoped permission naming/labels, middleware and trait enforcement, guard-aware checks in tameng:check, broader synchronization of resources/pages/widgets/custom permissions/role policies, and generated-policy lifecycle hooks. No breaking changes are called out, but the tameng:sync overhaul and panel-scoping behavior warrant regression testing in staging—especially if you already depend on custom permission names or hand-modified generated policies.