Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy / dependency shape. This is a thin Laravel bridge over papi-core — publishable config, env-var credentials, service-container binding, Laravel HTTP client wiring, centralized error handling. It adds no product capability on its own. The real "buy" decision is papi-core; this package is an optional convenience layer that saves roughly days of glue code, not weeks. Frame the decision that way or we'll approve the wrong dependency.
• Roadmap sequencing for runtime upgrades. v0.15.1 exists for exactly one reason: to require papi-core >= 0.15.3, where the PHP 8.5 fixes live. So this maps to a milestone question — "when can we move to PHP 8.5?" — and the paired bump is a prerequisite to schedule before the runtime upgrade, not after it.
• Feature scoping discipline. Nothing here defines a feature. If AI-backed endpoints are on the roadmap, the decision to make first is which AI API/vendor we integrate with. This package is plumbing at the end of that decision, and cheap to swap — a hand-rolled service class replaces it if needed. Don't let a wrapper choice masquerade as a product decision.
• Vendor concentration risk (explicit accept, not default). Adopting it means depending on a pre-1.0 ecosystem with 1 GitHub star, 0 dependents, and a one-paragraph public description. That belongs on the risk register as a supply-chain/concentration line item that product signs off on deliberately.
• Go/no-go framing. Treat this as a gate to clear via a timeboxed spike and a lockfile diff, not as a feature commitment. Revisit at 1.0.

When to Consider This Package

Consider it when:

• We have already committed to the PapiAI API and want the Laravel-idiomatic wiring instead of hand-rolling a client service. The savings are real but modest.
• We are planning a PHP 8.5 upgrade and need every dependency in the tree to declare compatibility — and we're already on papi-core.
• Engineering can co-bump this package and papi-core in the same change window, with a committed lockfile and explicit version constraints.
• We value reversibility: because it is a thin wrapper, backing it out later is a low-cost change.

Look elsewhere when:

• The AI vendor isn't chosen yet, or we're actively comparing providers. Picking the wrapper first inverts the decision order.
• We need semver stability, a support policy/SLA, a documented security posture, or an LTS window. None of that is evidenced here — a single release note is the entire public record.
• No one on the team already uses papi-core; then we're taking on two dependencies and two release cadences to reach one capability.
• We're on PHP 8.2/8.3 with no upgrade planned. This release is close to a no-op; there's no urgency and no reason to adopt under time pressure.
• Procurement or security review requires maintainer responsiveness, CVE history, or adoption breadth as a signal. 1 star and 0 dependents won't clear that bar on metadata — it would have to clear on code merit we haven't reviewed.
• We would be the first significant adopter. At this scale, assume we'd be funding the maintenance rather than consuming it.

How to Pitch It (Stakeholders)

Executives. This is a small, MIT-licensed Laravel add-on that connects our app to an AI API with minimal custom code. The honest framing: it's pre-1.0 (v0.15.x) with a very small public footprint, so it's a low-cost, reversible convenience — worth a short spike if AI endpoints are on the roadmap, not worth a platform commitment. The one thing it genuinely unblocks today is PHP 8.5 readiness: its latest release exists only to require a newer companion library that carries the 8.5 fixes. Recommendation: timeboxed evaluation, no exclusive dependency, revisit at 1.0.

Engineering. It's a thin Laravel bridge over papi-core — service provider, publishable config, env-based credentials, container binding, centralized HTTP error handling on top of Laravel's HTTP client. v0.15.1 adds no features; it only hard-requires papi-core >= 0.15.3. Sequence accordingly: bump papi-core first as its own PR with its own test pass, then bump this package, then diff the entire composer.lock — the transitive floor is the likeliest source of a surprise regression. Pin explicitly rather than floating (0.x minor bumps may break), and don't let an automated update rule drift it. Estimate roughly half a day if resolution is clean, more if papi-core is new to the codebase.

Caveat to state openly. The evidence base is one release note, a one-paragraph description, and repository metadata (1 star, 0 dependents, no stated support policy). Feature surface, security posture, supported PHP/Laravel matrix, and maintainer responsiveness are all unverified. Confirm composer.json constraints and release history before any go decision.