Laravel Inbox Laravel Package

Product Decisions This Supports

• Developer-experience roadmap. v1.1.0 ships resources/boost/guidelines/core.blade.php, offered to consuming apps via php artisan boost:install. This is a distribution channel for intended usage, not a runtime feature: the package now publishes canonical guidance that Laravel Boost surfaces to AI coding agents. Treat agent-facing documentation as a first-class product surface with its own release cadence.
• Build vs. buy. If your team is deciding whether to hand-roll this capability, weigh the package's AI-agent readiness as a real switching cost. Adopting a dependency that teaches Cursor/Claude/Copilot to use it correctly reduces the hidden integration tax that usually shows up as trial-and-error onboarding, and pushes it into a versioned artifact you inherit rather than author.
• Adoption-funnel measurement. Time-to-first-successful-usage is now partly mediated by an AI assistant. Instrument whether new adopters are arriving via agent-generated code, and whether that code is idiomatic. The Boost guidelines give you a lever to A/B (guidelines present vs. absent) against support-ticket volume and misconfiguration reports.
• Support and escalation load. Agent-authored snippets that use the package the wrong way generate a distinctive ticket class — plausible-looking code that fails on edge cases. Shipping guidelines is a pre-emptive support-cost decision; budget for it as such rather than as documentation polish.
• Ecosystem-positioning signal. Opting into Laravel Boost signals alignment with the framework's official AI tooling direction. Relevant if your roadmap includes Laravel-native integrations, starter kits, or anything where "works well with the default Laravel AI stack" is a differentiator.
• Release-management precedent. v1.1.0 is additive and semver-compliant: no breaking changes, no deprecations, no migration steps. It establishes that agent guidance versions alongside the package rather than floating free — worth codifying so future guideline edits are reviewed against the same compatibility bar as code.

When to Consider This Package

Adopt when:

• You are on a Laravel Boost-enabled codebase and want agents to reach for this package correctly without per-engineer prompting. If you are not using Boost, the v1.1.0 artifact is inert — it neither helps nor harms, and the release is effectively a no-op for you.
• Your team leans on AI assistants for scaffolding and glue code, and the cost of subtly-wrong generated usage exceeds the cost of one more dependency.
• You want the package's intended usage documented in a form that is versioned, template-driven (.blade.php), and updated by the maintainer rather than by your team.
• You are standardising a Laravel stack and want consistent agent behaviour across repos.

Look elsewhere or defer when:

• You are not on Boost. There is no runtime capability change here; evaluating this release as a functional upgrade would be a category error.
• Your constraints are runtime, e.g. performance ceilings, dependency footprint, license terms. This release notes says nothing about those, and the assessment carries no evidence on them.
• You need guarantees the maintainer has not published. A single release note is not a track record. If maturity, security posture, or long-term maintenance is decisive, this release provides no signal — go get direct evidence (repo activity, issue triage latency, CVE history, dependent-package breadth) before committing.
• You require a formal support contract or vendor SLA. Nothing here indicates commercial backing.
• Agents are not in your workflow. Then the value is close to zero and the decision should rest entirely on the package's functional merits, which this note does not describe.

How to Pitch It (Stakeholders)

For executives — one paragraph. The package published v1.1.0, adding built-in guidance so AI coding assistants use it correctly out of the box. It is a small, purely additive release — no breaking changes, no deprecations, no migration work — but it is strategically relevant: as more code is written with AI assistance, the quality of what those assistants know about a dependency becomes a real driver of onboarding speed and support cost. This release moves that knowledge from individual developers' heads into a versioned artifact the maintainer ships and updates. It is a low-cost, low-risk bet on the direction Laravel itself is heading.

For engineering leads — the practical framing. One new file, resources/boost/guidelines/core.blade.php, exposed through php artisan boost:install. It only takes effect in apps running Laravel Boost; everywhere else it is a no-op, so there is no reason to hold the upgrade. The reason to care: it gives us a maintainer-owned answer to "why does the agent keep generating the wrong call pattern for this package?" Instead of maintaining our own prompt snippets, we consume theirs and get the updates for free. Two asks — (1) verify the guidelines land as expected in one Boost-enabled repo before we rely on them, and (2) if we edit or override them, treat those edits as code with a review path, because they will silently rot otherwise.

Framing to avoid. Do not describe this as a feature release; it changes no runtime behaviour. Do not present it as evidence of the package's maturity, security, or maintenance health — it is a single data point about developer experience, and the assessment has no independent evidence on those other dimensions. If someone asks whether this makes the package safe to standardise on, the honest answer is: it makes it easier to adopt correctly, which is a different and narrower claim.