Supercharged Enums Laravel Package

Product Decisions This Supports

• Build vs. buy for enum behaviour: instead of hand-rolling label/colour/transition helpers on every backed enum, the package standardises it behind a single EnumExtension trait. This is a low-risk "buy" (composer require) decision that removes a recurring 20–60 line per-enum invention tax across teams.
• Domain-modelling consistency (roadmap hygiene): status, state, role, and type enums are the most-touched value objects in a Laravel product. Standardising their shape makes it cheaper to refactor workflows, add admin filters, or expose enum values through APIs later — decisions PMs routinely schedule without estimating the per-enum plumbing cost.
• Developer velocity / onboarding: the make:enum stub means new enums are correctly wired by default rather than relying on tribal knowledge. Relevant to any decision about hiring ramp-up time, contractor onboarding, or "why is our codebase inconsistent" retro items.
• AI-assisted development posture: shipping a Boost skill plus guidelines means the package actively participates in agentic coding (Copilot/Cursor/Claude-style workflows). This supports the roadmap question "are we investing in AI tooling for the team, or only consuming it ad hoc?" — a package that auto-registers with boost:install is a zero-effort yes.
• Documentation-as-code signal: shipping guidelines under resources/boost/ and validating their structure in tests is a maturity indicator. Useful evidence when judging whether a dependency will rot or be maintained.
• Use cases to scope: admin panels and filters driven by enum values; state machines and transitions; API resources serialising enum labels; feature flags or tiered plans modelled as enums; any product surface where "the label shown to users" must live next to "the value stored in the database."

When to Consider This Package

Adopt when:

• You are on PHP 8.1+ / a Laravel version with backed enums and package discovery and already use enums for business states — the value is proportional to enum count. A codebase with two enums gains little; one with twenty gains consistency.
• You want generated enums to be correct by default (make:enum producing pre-wired EnumExtension) so the convention survives turnover and AI-generated pull requests.
• You care about AI agent accuracy on your codebase: the Boost skill/guidelines reduce the chance an agent invents its own enum helpers, which is a real source of review churn.
• You need low integration cost: no migrations, no config surface, no runtime services — the risk profile of a dev-experience package, not an infrastructure one.
• You are standardising across multiple Laravel services and want one enum contract everywhere.

Look elsewhere or defer when:

• The team has a strong existing enum convention (custom traits, native Enum methods, or a Enumable cast in an internal package). Two competing conventions is worse than one imperfect one.
• You are on a legacy Laravel/PHP version without backed enums, or use a non-Laravel PHP stack where the service provider and stubs are dead weight.
• You need persistence layer behaviour (database casts, query scoping, enum-backed lookup tables) — this package is a language-level ergonomics layer; evaluate Laravel's native casts and a lookup-table design separately.
• You require long-term vendor guarantees: v0.2.0 is pre-1.0. Assume breaking changes; budget for pinning and periodic review. If the enum layer is mission-critical, consider vendoring or wrapping it behind an internal interface.
• Your AI tooling isn't Boost-based — the guidelines are still readable, but the auto-discovery benefit is conditional.
• Dependency count is a governance constraint: every package is supply-chain surface. Small and readable mitigates but does not eliminate this.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, developer-experience package that standardises how our application represents business states — order statuses, user roles, plan tiers — so the same behaviour isn't rebuilt slightly differently in every feature. Version 0.2.0 makes it self-installing: new enums are generated correctly by our existing tooling, and it now registers with our AI coding assistants so generated code follows our conventions instead of inventing new ones. Cost is near zero (no infrastructure, no migrations, one Composer dependency); the return is consistency, faster onboarding, and less review churn. It is pre-1.0, so we pin the version and treat upgrades as deliberate.

To engineering leadership: Single trait (EnumExtension) applied to backed enums; service provider auto-registered via package discovery; opt-in stub publishing via one artisan command. No runtime services or database footprint. Boost skill and guidelines ship in-repo and are test-validated, so they won't silently drift. Ask: (1) do we consolidate on this trait or keep our internal one? (2) who owns the version-pin and upgrade review? (3) do we publish the stubs, or accept defaults?

To engineering (implementation note): Two commands to evaluate — php artisan vendor:publish --tag=supercharged-enums-stubs then php artisan make:enum Status --string; verify the generated file matches house style before rolling out. Confirm whether boost:update --discover is part of your AI tooling setup so the skill is picked up rather than sitting unused.