Conduit Interfaces Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel Zero 11 → 12): v1.1.0 widens laravel-zero/framework and illuminate/console constraints to ^11.0|^12.0. This is the concrete unblocker for any product built on Laravel Zero that is being held back on v11 solely because of this dependency. If your roadmap includes a Laravel Zero 12 migration, this release removes (or confirms the absence of) a blocker.
• Build vs. buy / build vs. adopt: conduit-interfaces is an abstractions/contracts package — it supplies interfaces, not runtime features. The decision it informs is not "should we buy this product" but "should we depend on a shared contracts layer instead of rolling our own internal interfaces." Adopting shared contracts buys interoperability with the wider Conduit ecosystem; the trade-off is coupling to a small third-party package's release cadence.
• Component architecture and code reuse: The release note explicitly frames the value as enabling "better component architecture and code reuse" for projects like THE SHIT. For a PM, that translates to lower long-term maintenance cost across multiple CLI tools that can now share a common contract surface rather than duplicating interface definitions per project.
• Backward compatibility as a roadmap signal: Maintaining ^11.0 alongside ^12.0 means the package is not forcing a coordinated multi-repo upgrade. That reduces sequencing risk in the roadmap — teams can upgrade on their own schedule rather than as a single flag day.
• Dependency-risk sizing: This is a low-blast-radius dependency (interfaces only). A constraint bump here carries materially less product risk than a framework or ORM bump, which is useful when triaging upgrade work against feature work.

When to Consider This Package

Consider it when:

• You are building or maintaining CLI applications on Laravel Zero, and you want shared contracts rather than project-local interface duplication.
• You have (or plan) multiple interlocking CLI components that need a common vocabulary for dependency injection and cross-package typing.
• You are migrating to Laravel Zero 12 — v1.1.0 is the first version that permits it, so this is the minimum version to pin if v12 is on your roadmap. Pin ^1.1 rather than ^1.0.
• Your team is already inside the Conduit ecosystem and consistency across components has real value.
• PHP 8.2+ is acceptable in your runtime baseline (this release states PHP 8.2+; confirm against your actual deployment floor before committing).

Look elsewhere — or build internally — when:

• You need runtime behavior, not contracts. An interfaces-only package will not solve functional requirements, and adopting it for "features" will disappoint stakeholders.
• You run a single, self-contained CLI tool. The reuse argument does not apply, and you take on an external dependency for near-zero benefit.
• You are pinned to Laravel Zero 10 or earlier, or to PHP below 8.2. This release does not help you, and you should verify whether older tags are still supported before assuming the package is viable at all.
• You require a stable, widely-adopted dependency with a visible maintenance history. There is no prior assessment on file and the changelog spans only v1.0.0 → v1.1.0, so treat maturity and bus-factor as open questions to resolve before deeper adoption.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost dependency update with one meaningful consequence — it clears a blocker on our Laravel Zero 12 upgrade path. No new product surface area, no user-facing change, no migration effort required on our side. The value is risk reduction and reduced duplicated code across our CLI tools, not new capability.

For engineering: v1.1.0 relaxes the laravel-zero/framework and illuminate/console constraints to ^11.0|^12.0, preserving Laravel Zero 11 compatibility while enabling Laravel Zero 12. PHP 8.2+ required. The package provides contracts/interfaces only — expect no runtime behavior changes from the bump. Recommended action: bump to ^1.1 in any Laravel Zero project, confirm the PHP 8.2 floor matches our CI and deploy images, and proceed with the v12 upgrade in dependency order. Because backward compatibility is retained, this can be adopted incrementally per repository with no coordinated release.

Caveats to state up front: interfaces-only packages deliver architectural value that is difficult to attribute to a business outcome — do not attach feature-level expectations to this. And with only two published versions and no prior assessment, validate maintenance activity and release cadence before making it a load-bearing part of the component architecture.