Laravel Feedback Board Laravel Package

Product Decisions This Supports

• Build vs. buy for the feedback loop. This package covers the entire path from an in-app report button to a developer triage board, notifications, and issue mirroring. Adopting it replaces a scoped-but-real build (custom form, attachment storage, status model, reporter portal, board UI) with a composer require and an install command — a decision that is cheap to reverse and cheap to trial.
• Whether to invest in AI triage. Triage is opt-in, ships with Anthropic/Gemini/OpenAI drivers, and is extensible via FeedbackBoard::extendTriage(). That lets you test auto-classification of type/priority as a product hypothesis without committing to a provider or a vendor contract — and the "developer applies one field at a time" interaction keeps a human in the loop, which is the right default for anything that touches prioritisation.
• Support/dev workflow ownership. Reporter chat, internal notes, activity feed, assignee/priority, and unread markers on one board means one system of record for "what users are telling us" instead of feedback living in a form inbox and tickets living elsewhere. Worth deciding deliberately: is the board the system of record, or is GitHub/Jira? The package assumes the former with one-way-ish GitHub mirroring.
• Auth and segmentation model. Multi-guard support (auth.guards, auth.developer_guards, FeedbackBoard::user()) and separate reporter/developer resolvers are the deciding features for multi-sided products — staff on web, clients on a Filament panel guard. If your product is single-guard, these are inert; if it isn't, their absence would be disqualifying.
• Tenancy posture. Reports are app-wide, not tenant-scoped. That's a product decision you must make consciously: fine for internal tools and single-tenant SaaS, likely wrong for a multi-tenant B2B product where a support agent from tenant A shouldn't see tenant B's reports.
• Integration surface as a hedge. Webhook, Slack, GitHub issues, and the HMAC-signed ingest endpoint (for CI or agent runners to write back) mean the package can be the intake layer while your delivery layer stays wherever it already is.
• Notification defaults. Mail is on, database notifications are opt-in, delivery failures never lose the user's action, and destination failures are surfaced to developers with a once-a-day email cap. Reasonable defaults; the daily-cap choice is worth confirming against your on-call expectations.

When to Consider This Package

Consider it when:

• You run a Laravel app, and especially if you already run Filament 4/5 — the plugin gives you My Reports, the Kanban board, and a reports resource inside your existing panel with the panel's theming, dark mode, and navigation.
• You want a reporter-facing surface distinct from the internal tracker: signed-in users file reports, follow progress, and chat; developers get a board. Guests are hidden from the launcher, so it can live in a layout shared with a login page.
• You need multi-guard auth — staff and clients on different providers — and want the package's routes to authenticate across them rather than building that plumbing.
• You want escape hatches rather than a black box: gates (feedback-board.manage, feedback-board.report), resolvers, linkReportsUsing(), extendTriage(). The fail-safe resolver behaviour (throws or non-boolean returns deny and are logged once rather than breaking the page) is the kind of detail that matters in production.
• You can live with app-wide reports and GitHub as a one-way-ish mirror (comments appended to issues; no inbound sync from GitHub into the package).

Look elsewhere when:

• You need public roadmap/voting/changelog as the core product (upvotes, public boards, subscriber notifications). This is an internal-facing intake and triage tool, not a Canny replacement.
• You require per-tenant isolation of feedback, or per-tenant developer scoping.
• You need two-way issue-tracker sync (Jira/Linear as system of record, with status flowing back), or non-GitHub destinations built in.
• You are not on Laravel, or you want to avoid coupling this much surface area to a single-maintainer package.
• You need enterprise assurance: published security policy, SLA, long-term maintenance commitments. None of that is evidenced here.
• You need self-hosted/on-prem model inference for triage — the OpenAI-compatible base_url covers many gateways, but verify it covers yours before assuming.

Adoption caveat for this specific release: v1.0.2 is a package rename/republish (yousefaman/laravel-feedback-board) with code identical to 1.0.0 and 1.0.1. Before adopting, verify the previous package name, confirm the namespace and vendor are the ones you intend to depend on, and pin an exact version. Renames on Packagist are a normal but real dependency-hygiene signal — treat the vendor identity as part of the build-vs-buy calculus.

How to Pitch It (Stakeholders)

For executives: We can close the loop between what users report and what we build, in days rather than a quarter. Users report from inside the product with a screenshot and the page they were on; developers triage on a board and reply in the same place. Notifications and Slack/GitHub mirroring mean the people who need to know already do. AI triage is opt-in and provider-agnostic, so we can measure whether it improves routing before paying for it. Cost is one dependency and a config file, not a headcount.

For engineering: One composer require plus php artisan feedback-board:install. Config, routes, and tables are stable across 1.0.x; access control works with config:cache; resolvers deny safely instead of throwing; webhook/Slack/GitHub deliveries are queued, isolated per destination, retried on a fixed backoff, and fail fast on un-retryable errors, with secrets kept out of exception messages and job payloads. The ingest endpoint is HMAC-signed, single-use per signature, Content-Type-strict, and can share nonce state across servers. If you already run Filament, the plugin reuses the panel's guard, tenancy, theme, and navigation — no second admin surface to maintain.

What to flag in the room: the 1.0.2 republish means a dependency-name change to absorb now; reports are app-wide, so multi-tenant isolation is a decision, not a default; and the AI runner contract (Level B/C) is a large, fast-moving surface — pilot it behind a flag rather than adopting it on day one.