Filament Audiofeedback Laravel Package

Product Decisions This Supports

• Admin UX differentiation (build vs. buy): Adding audible cues to a Filament admin panel is a small, non-core capability. This package is a "buy/borrow" answer — adopt instead of spending engineering sprints building sound assets, user preference storage, and per-panel settings wiring in-house.
• Accessibility and attention-management roadmap: Audio feedback matters for operators working in high-throughput back-office screens (support desks, order queues, kiosk/label-printing stations) where the screen isn't continuously watched. It supports decisions like "do we invest in notification/attention design this quarter?" with a low-cost experiment rather than a platform commitment.
• Personalization / user-preference roadmap: The package ships a settings table and translations, which is a signal that per-user preferences (on/off, sound selection, locale) are a first-class concern — useful evidence when scoping a broader "user preferences" or "workspace settings" initiative.
• Feature-flag and pilot decisions: Because it's a self-contained Filament plugin, it can be piloted on one panel or one team before any product-wide rollout — a cheap way to validate whether audible alerts improve response times or reduce missed items.
• Dependency governance: The v1.4.0 rename is a concrete input to the "third-party package inventory and upgrade cadence" decision — who owns the composer constraint, who runs the migration, who validates assets after deploy.

When to Consider This Package

Consider adoption when:

• Your product runs on Filament (Laravel admin panels) and the team already accepts Filament-ecosystem plugins as an extension strategy.
• The workflow has a latency-sensitive or unattended element — queues, ticket desks, on-call dashboards, warehouse/fulfilment stations — where a missed event has real cost.
• You want configuration over code: a settings table plus published config and translations means product/ops can adjust behavior without a release.
• You need multi-locale support out of the box via the translation namespace.
• You can absorb a composer-level rename with a short migration window (see below) and have a named owner for the constraint bump.

Look elsewhere (or build in-house) when:

• Your admin panel is not Filament, or you're mid-migration off it.
• The user base is predominantly shared-office/quiet environments or the product has strict accessibility requirements where sound must be fully user-controllable and audited — validate the opt-out and persistence behavior first.
• You need audible alerts outside the browser (SMS, push, paging, hardware) — this is in-panel feedback only.
• Your policy forbids third-party UI plugins in admin surfaces, or you require vendor SLAs and security review of every added dependency.

Migration note for v1.4.0 (breaking, composer-level): the package was renamed from blemli/filament-audiofeedback to blemli/audiofeedback-for-filament. Namespace, plugin class, config key, translation namespace, routes and the audiofeedback_settings table are unchanged, so application code should not need edits — but composer.json constraints, lockfiles, CI caches, and published asset paths change. Published assets now live under public/{js,css}/blemli/audiofeedback-for-filament/; stale directories from the old name must be deleted and php artisan filament:assets re-run. Treat this as a scheduled maintenance ticket with a rollback plan, not a silent patch bump.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add audible feedback to our Filament admin panel — sound cues when an action succeeds, fails, or needs attention — by adopting a small, actively maintained open-source plugin instead of building it. The business case is narrow but real: for teams working queues or unattended screens, missed events cost time and money, and this is a low-cost, reversible experiment we can pilot on one panel and measure. The trade-off is one more third-party dependency in a sensitive surface and a short, well-understood migration this release.

For engineering:

• Filament plugin; install via composer, publish config/assets, run migrations for the settings table. Config key, translations, routes and table names are stable across the rename.
• v1.4.0 is a rename-only release with a breaking composer package name plus a moved asset publish path. No namespace or API changes. Effort is roughly: constraint bump, lockfile refresh, asset republish, delete stale public directories, smoke-test one panel.
• Two small quality signals in this release: the install command no longer nags about starring the repo, and the uninstall command now correctly removes the published stylesheet directory — i.e. the package is being maintained with cleanup hygiene, and removal is clean if we back out.
• Suggested guardrails before rollout: pin the exact version, verify the settings table migration in a staging restore, confirm user-level opt-out persists, and add the package to our dependency-review list with a named owner.

Recommendation: Proceed to a time-boxed pilot on a single panel, with the v1.4.0 rename migration handled as its own ticket. Re-evaluate after the pilot on measured outcomes (missed-event rate, response time, user complaints) rather than on feature appeal.