Filament Developer Tools Laravel Package

Product Decisions This Supports

• Build vs. buy for internal tooling: tomatophp/filament-developer-tools is a Filament plugin that packages developer-facing utilities (typically artisan/command runners, log and error inspection, and environment/debug helpers) directly into an existing Filament admin panel. The decision this supports is whether to spend engineering sprints replicating these screens in-house or adopt a plugin and redirect that effort to core product work.
• Roadmap sequencing for admin/back-office surfaces: if the team already ships Filament panels, adding a developer tools panel is a low-marginal-cost capability. It can be scheduled as a small, contained item rather than a standalone project, and it does not compete with customer-facing roadmap capacity.
• Support and on-call cost reduction: self-service diagnostic screens reduce the "ask an engineer to tail the log / re-run the command" tax on support and on-call rotations. This is a measurable operations decision (fewer escalations, faster triage), not just a developer convenience.
• Risk posture for the dependency portfolio: v0.0.1 is a first public release with no prior assessment history, no documented feature list in the release notes, and no changelog detail beyond a commit link. The decision this informs is classification — this package belongs in the evaluate / spike bucket, not the adopt for production bucket, until the maintainer publishes real release notes and a version history.
• Ecosystem alignment check: choosing a TomatoPHP-maintained plugin is a bet on that vendor's release cadence and Filament major-version tracking. That belongs in the same decision as the feature comparison.

When to Consider This Package

Consider adoption when:

• The application already runs Filament (v3/v4 as applicable to the release — verify compatibility, since this is unstated in the v0.0.1 notes). If you are not on Filament, this package has no surface to attach to.
• The panel is internal or staff-only, gated behind authorization. Developer tools expose logs, command execution, and environment details; they are a privilege-escalation surface if reachable by untrusted users.
• You have an existing need for command execution or log inspection from a browser, and no policy forbidding it. Some organizations prohibit web-triggered artisan commands outright — check that before evaluating features.
• You can pin the version and accept pre-1.0 churn. Treat v0.0.1 as an experiment with an exit plan.

Look elsewhere when:

• Stability is a requirement. A 0.0.1 with no substantive release notes gives you nothing to assess for breaking-change risk, security posture, or feature completeness. Requiring ≥1.0, or a maintainer with a documented changelog, is a reasonable gate.
• You need production-grade observability. Purpose-built tools (Laravel Telescope, Sentry, Laravel Pulse, dedicated log aggregation) cover diagnostics with better maturity, access control, and retention semantics. This plugin is a convenience layer, not a replacement.
• Security review cannot be completed. Web-triggered command execution is high-blast-radius. If you cannot audit the middleware/authorization, do not ship it.
• Filament compatibility is unconfirmed for your version.

How to Pitch It (Stakeholders)

For executives: A small, free, community-maintained add-on that puts developer diagnostics inside the admin panel we already have. The value case is reduced engineering interruption for routine troubleshooting — engineers stop context-switching to run commands and read logs for support requests. The cost case is near zero (a Composer dependency, no infrastructure). The recommendation is a time-boxed evaluation, not a production commitment: this is version 0.0.1 with no changelog, so we should validate it in a sandbox before it touches anything customer-adjacent. Worst case we remove one dependency.

For engineering: Filament plugin from TomatoPHP adding developer tooling to a panel. v0.0.1 is the initial public release; the release notes contain only a commit link, so treat the feature list as unverified until someone reads the source. Ask of the team: a short spike covering (1) Filament version compatibility, (2) the authorization/middleware model — confirm the tools are unreachable without an explicit gate, and (3) whether command execution is in scope at all given our policy. Pin the version; assume breaking changes across 0.0.x. If the spike passes, ship it behind a superadmin gate on an internal panel only. If the spike stalls on security review, default to Telescope/Pulse and move on.