Laravel Say Logger Laravel Package

Product Decisions This Supports

• Developer-experience / internal tooling investment (low stakes). This is a ~zero-cost morale and ergonomics play for local development, not a platform dependency. It informs whether we allocate any DX budget to "delight" tooling versus strictly functional tooling — the answer here is almost certainly "yes, but timeboxed and opt-in only."
• Accessibility and ambient-alerting use case evaluation. The only genuinely product-relevant capability is audible log-level alerting: an error or emergency can reach a developer who is not watching the terminal. This supports a decision on whether to pursue an out-of-band alerting path (Slack/PagerDuty/desktop notifications) versus a novelty channel — and the answer is that this package is a prototype of the idea, not the implementation.
• Build vs. buy for novelty features. Cost of building is trivial (a thin wrapper around the macOS say binary plus a Monolog handler). This argues against formal adoption governance, procurement, or vendor review — it should be treated as a dev-dependency curiosity, not a vetted package.
• Roadmap signal on log-driven workflow tooling. If developers react well to log events being surfaced more aggressively, that's a signal to invest in structured log routing and notification fan-out — not in TTS specifically.
• Explicitly not a production observability decision. Nothing here should influence our choice of log aggregation, alerting, or APM vendor.

When to Consider This Package

Adopt only when all of the following hold:

• The developer machine is macOS — the package depends on macOS's built-in say voices. It is non-functional on Linux, Windows, and in every container/CI/production environment we run.
• It is installed as a require-dev dependency and wired into a local-only logging stack (e.g., a local or dev stack in config/logging.php), never into a stack that could activate in staging or production.
• Log lines are known not to contain PII, credentials, or customer data — or the channel is scoped to a narrow set of internal events. Log content becomes audio output, which is audible to anyone in the room and is not covered by our usual log-retention and access controls.
• The team accepts unmanaged shell execution: speaking text means building and executing a shell command with log content as an argument. Treat quoting/injection surface as a real risk until reviewed.
• Async processing is verified, not assumed — if speech synthesis blocks the request/worker thread, it can serialize queue workers and degrade local performance.

Look elsewhere when:

• You need cross-platform or server-side audible alerting — use desktop notifications, Slack webhooks, PagerDuty, or terminal bell/message hooks instead.
• You want serious log-driven alerting — this is not that; the level→voice mapping is decorative, not routable or configurable in an operational sense.
• Security review or compliance applies — shell exec with log payloads, plus audio broadcast of internal data, will not clear review.
• You are on Laravel < 10 or on a PHP version outside the stated support matrix.
• You want a maintained dependency — v1.0.0, single-author, AI-scaffolded, novelty scope. Expectation of long-term maintenance should be near zero; do not build anything on top of it.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source novelty package that reads Laravel log messages aloud on a developer's Mac using the operating system's built-in voices. It has no customer-facing impact, no infrastructure cost, and no production applicability — it cannot run on our servers. We're treating it as an optional local developer toy, not an approved dependency, and there is nothing here requiring budget, procurement, or a launch decision.

To engineering: If you want to try it, install it as a require-dev, attach it only to your local log stack, and assume it does not work on Linux, in Docker, or in CI. Two things to check before you do: confirm the package quotes log text before shelling out (log content reaching a shell is an injection surface), and confirm the "async" claim actually holds so speech doesn't block your worker. Do not let it anywhere near a stack that can run in staging or production, and don't log anything you wouldn't want spoken out loud in a shared room. It's a five-minute morale win and a fun demo of log-level routing — evaluate it in that spirit, not as an alerting strategy.