Firewatch Laravel Package

Product Decisions This Supports

• Observability strategy / build-vs-buy for telemetry access. Firewatch is a thin adapter, not a monitoring platform: it persists what Laravel Nightwatch's sensors already collect into a local SQLite file and exposes it over the Model Context Protocol. The decision it informs is "how do we get value out of the Nightwatch data we're already paying to collect?" rather than "should we adopt Nightwatch?" Treat it as an additive layer on an existing or planned Nightwatch investment.
• AI-assisted development roadmap. It is one of the first concrete integrations between a Laravel app's runtime telemetry and an AI coding assistant. If your roadmap includes agentic debugging, MCP-based tooling, or "let the assistant read the app's own traces," this is a low-cost way to validate that workflow on a real squad before committing to a broader internal tooling bet.
• Developer experience and time-to-diagnosis. The value proposition is measurable: reduce the loop from "something is slow/failing locally" to "here is the query/request/exception the assistant can reason about." Worth a scoped experiment with a baseline (e.g. median time to root-cause on seeded bugs) rather than an open-ended rollout.
• Data-handling review. Local SQLite retention keeps raw telemetry on the developer machine and out of a hosted retention window. That is a genuine input to privacy/security review — but scope it honestly: MCP query results are still surfaced to the AI assistant, so this is not a data-residency solution, only a change in where the primary store lives.
• Cost/retention modelling. A local store can complement paid Nightwatch retention by letting engineers re-query older local traces without upgrading a SaaS plan tier. Useful input if you are sizing an observability contract.
• Not a production operations decision. Nothing in v1.0.0 suggests alerting, dashboards, SLO tracking, or multi-service aggregation. Do not let it enter an APM/platform evaluation; it is a developer-tooling line item.

When to Consider This Package

Consider it when:

• Your stack is Laravel/PHP and you are already running Laravel Nightwatch, or are actively piloting it — Firewatch depends on Nightwatch's sensors existing in the first place.
• Your engineers use an MCP-capable AI assistant (Claude Code, Cursor, or similar) in day-to-day work, so the "query it over MCP" surface is actually reachable by someone.
• The target environment is local development, CI, or per-developer sandboxes — where a throwaway SQLite file is acceptable and no operational guarantees are expected.
• You want a cheap proof point for agentic debugging before funding bespoke internal tooling.
• You need traces to stay on the developer machine for review reasons, accepting that query output still reaches the assistant.

Look elsewhere when:

• You need production APM: alerting, uptime, error aggregation across services, dashboards, retention policy, or an on-call story. Buy a monitoring platform.
• You are not on Nightwatch and have no intention of adopting it. The package has no standalone value; it captures, it does not collect.
• You require vendor support, an SLA, or a named maintainer team. This is a v1.0.0, single-maintainer, community package from an individual author.
• Your security posture forbids sending application telemetry or query results into an AI provider's context — MCP does not sidestep that.
• You need stability guarantees across dependency upgrades. The package necessarily tracks Nightwatch's internal sensor output; expect coupling to Nightwatch versions and possible breakage between minor releases of either. Pin versions and re-validate on upgrade.
• Strict change-control environments where a brand-new 1.0.0 dependency with an unproven upgrade history is unacceptable.

Recommended adoption shape: pilot, not standardise. One squad, one repository, pinned versions, local/CI only, with a documented review checkpoint after a quarter.

How to Pitch It (Stakeholders)

To executives: A small, free, community-built add-on that lets our AI coding assistants read the Laravel runtime telemetry we already generate, instead of an engineer manually digging through logs. The hypothesis is faster diagnosis and less senior-engineer time spent on routine triage. Cost and switching cost are near zero; the risk is equally low because it is scoped to developer machines and never touches production traffic. Recommend a one-quarter, one-team pilot with a measured time-to-diagnosis baseline, and a decision at the end to keep, drop, or invest in internal tooling.

To engineering: Firewatch writes Nightwatch's sensor output to a local SQLite file and serves it over MCP, so your assistant can query real request/trace data during development. It is deliberately narrow — it captures and exposes, it does not monitor. Constraints to accept up front: it is v1.0.0 with a single maintainer, it is coupled to Nightwatch's sensor output and will need re-validation on upgrades, and it is a local-dev tool, not something we run in production. Pin the version, keep it to local and CI, and flag any Nightwatch upgrade as a re-test trigger.