Tactician Command Events Laravel Package

Product Decisions This Supports

• Observability of write paths as a product requirement. If the roadmap includes audit trails, "who did what, when" compliance features, or per-action activity feeds, lifecycle events around command handling give product a single hook point instead of instrumenting every handler individually.
• Build vs. buy for cross-cutting concerns. Side effects that are not core domain logic — analytics, notifications, cache invalidation, search indexing, webhook fan-out — can be attached to command events rather than hard-coded into handlers. This determines whether these ship per-feature (slower, inconsistent) or as a platform capability (faster, consistent).
• Feature scoping for an event-driven architecture. Teams evaluating "should commands emit events?" get a cheap reference implementation: it lets you prototype async/decoupled workflows (e.g., order placed → provisioning, email, ledger) before committing to a heavier broker (Symfony Messenger, Laravel queues + domain events, Kafka).
• Technical debt triage. The decision here is usually not "adopt vs. reject" but "adopt, fork, or reimplement in ~1 day." Zero stars, zero dependents, and a last release in May 2021 mean the real product decision is ownership cost, not capability.
• Risk acceptance for existing Tactician users. Only relevant if the codebase already runs a Tactician command bus; otherwise this package informs no roadmap item.

When to Consider This Package

Adopt or evaluate only when all of these hold:

• The codebase already uses league/tactician as its command bus (or is migrating to it) and will not standardize on Laravel's native jobs/events or Symfony Messenger.
• You need command lifecycle signals (pre-handle, post-handle, success, failure) as a first-class extension point for audit, metrics, or side-effect fan-out.
• You are comfortable vendoring or hard-forking the source: MIT license permits it, but with 0 stars, 0 dependents, and no release since 2021, there is no community, no security response path, and no Laravel 11/12 compatibility guarantee. Treat it as sample code, not a dependency.

Look elsewhere when:

• The application is a standard Laravel app — Laravel's event dispatcher, model/domain events, job middleware, and Event::listen cover the same ground with first-party support and no maintenance risk.
• You need guaranteed compatibility with modern PHP/Laravel, typed properties, or attribute-based listeners.
• You require SLA-backed support, ongoing security patches, or a vendor to escalate to.
• The team lacks capacity to own a fork — an unmaintained package with no dependents is a future upgrade blocker, not a shortcut.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed extension that lets our command bus publish events when commands start, succeed, or fail. It would let us deliver audit logging, activity feeds, and cross-cutting side effects as a reusable platform capability rather than rebuilding them inside each feature — a modest speed gain on several roadmap items. The caveat is that the project is effectively abandoned: no releases since 2021, no users, no maintainer support. Recommendation is to treat it as a design reference and implement the equivalent internally (roughly a one-to-two-day effort) rather than take a dependency on it. That preserves the product benefit — consistent observability and decoupled side effects across features — while keeping the upgrade path and security posture fully under our control.

For engineering: Evaluate as reference implementation only. Port the lifecycle-event pattern onto our existing bus with tests and Laravel-version coverage; do not add the package to composer.json.