Logger Core Laravel Package

Product Decisions This Supports

• Build vs. buy — build wins. The entire scope is a logger trait: a nullable LoggerInterface property, a lazy getLogger(), and a setLogger() setter. That is an afternoon of internal code. Adopting a dependency for it buys us supply-chain tracking, version-constraint management, and upgrade risk in exchange for roughly thirty lines we could own outright.
• Architecture / standards decision — PSR-3 as the seam. The one durable idea worth extracting is "log against Psr\Log\LoggerInterface, not the Log facade," so domain services, jobs, and SDK-style clients stay framework-agnostic and testable with a NullLogger or TestLogger. That is a coding-standard decision we can make and document without the package.
• Roadmap fit — none, and that is the decision. No user-facing feature, market segment, or delivery milestone depends on this. Its only roadmap relevance is defensive: explicitly exclude it from our Laravel/Lumen service template so it does not arrive transitively and become someone's accidental dependency.
• Testability as the real lever. The genuine PM-relevant value is that trait-style injection lets teams assert on log records instead of spying on the framework. If we want that property across services, we get it by mandating constructor-injected LoggerInterface in our own conventions — cheaper and better than a package that stores the logger on the instance.
• Lifecycle signal overrides the feature signal. The repository sits under a GrahamDeprecated org, has zero stars and zero dependents, and its headline quality evidence is "added a couple of tests." Treat it as an archived artifact, not a candidate. The v1.1.0 "official Lumen support" line is a historical footnote, not an adoption argument — do not let a changelog entry reverse a deprecation signal.
• Risk register entry, not a backlog item. The most likely production failure is serialisation: the trait stores the logger on the object, so a queued job carrying it will drag Monolog handlers (and their closures) into the payload and fail to unserialise. A psr/log major-version mismatch is the second. Both are avoidable only if we control the code.

When to Consider This Package

• Consider it only if we are already inside Graham Campbell's logger family and need the shared base a higher-level integration depends on. It is an implementation detail of that ecosystem, not a standalone product choice.
• Consider a read-through, not adoption, if we are designing our own logging abstraction and want a reference for trait-based reuse and PSR-3 handling. Budget an hour, not a sprint.
• Look elsewhere — or write it ourselves — in every other case: we need framework support commitments, a maintained dependency, a security review trail, or a published version matrix.
• Do not adopt for new Laravel or Lumen services. Deprecated status plus zero dependents means no community will surface bugs before we do, and an unmaintained package inside the observability path can pin an entire framework upgrade.
• Do not treat "official Lumen support" as a compatibility guarantee; there is no version matrix, CI detail, or support window, and the second framework path is almost certainly under-exercised.
• Do not use it in controllers or Eloquent models. Log::, logger(), or constructor injection already solves that with channels, handlers, and context configured — reaching for the trait there is a net loss.
• Re-open the question only if the package is un-deprecated and picks up real dependents. Otherwise close it and move on.

How to Pitch It (Stakeholders)

• Executives: This is a small, retired utility library. It delivers no customer, revenue, or compliance value, and adopting it adds a dependency we would have to track and eventually replace. Recommendation: do not adopt; no decision or budget required.
• Engineering: The capability is a reusable logger trait plus PSR-3 plumbing — about a day of our own code with full ownership, real tests, and a constraint we choose. Upstream is under a GrahamDeprecated org, has zero dependents, and its test suite is described as "a couple of tests." It also carries two known sharp edges: the logger is stored on the instance and will break serialisation of queued jobs, and its psr/log constraint may not match our Laravel major. If the pattern is useful, copy the idea — not the dependency.
• Product: No roadmap impact either way. The single action worth taking is a one-line note in the service template's dependency guidance so this package does not get pulled in by transitive habit, plus a standards line preferring constructor-injected LoggerInterface over trait-based logging.