Laravel Inbox Laravel Package

Getting Started

1. Install the package with Composer using its documented constraint: composer require <vendor>/<package>.
2. Publish any config, migrations, or assets the package ships: php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider". Run php artisan migrate only if migrations are published.
3. Look here first: the package README.md, the service provider (src/<Package>ServiceProvider.php), and config/<package>.php. Then read resources/boost/guidelines/core.blade.php — as of v1.1.0 this is the package’s own guide for AI coding agents and is the fastest way to understand intended usage, commands, and conventions.
4. Laravel Boost setup: if the app uses Laravel Boost, run php artisan boost:install and select this package. Boost renders the Blade guidelines into the app’s AI context so agents follow the package’s intended patterns instead of guessing.
5. First use case: wire the package into one feature (a controller action, job, or artisan command) and cover it with a feature test. Then ask your AI agent to extend that test using the Boost guidelines. This validates both the package integration and the quality of the generated guidance.

Implementation Patterns

• Treat the Boost guidelines as executable documentation. After boost:install, keep the generated guidelines in version control. When the package updates, re-run boost:install and review the diff to see what behavior guidance changed.
• AI-assisted feature work: prompt the agent to read the generated guidelines (or resources/boost/guidelines/core.blade.php) before generating code. This is the main day-to-day lever in v1.1.0: fewer hallucinated APIs, correct config keys, and correct command names.
• Resolve from the container. Inject the package’s services, facades, or contracts rather than instantiating classes manually. Bind interfaces in an app service provider if the package exposes contracts.
• Keep a thin integration layer. Wrap package calls in your own action or service class. This isolates AI-generated code and tests from package internals and makes future upgrades less disruptive.
• Test each integration point. Write one feature test per package touchpoint. Prefer the package’s fake/test doubles over hitting external services, and assert the behavior the guidelines describe.
• Keep local and CI agents aligned. Commit the generated guidelines so every developer’s agent gets the same instructions. Put app-specific overrides beside the generated file rather than editing the package’s Blade template.
• CI drift check: if you want to catch guideline drift, run the Boost installer non-interactively in a setup step and diff the generated output before running the normal test suite.

Gotchas and Tips

• Boost guidelines are opt-in. php artisan boost:install only offers the package’s guidelines during install. If you added the package before v1.1.0 or skipped the prompt, agents will not see them. Re-run the installer after upgrading.
• Regenerate after package updates. The source guidelines live in the package at resources/boost/guidelines/core.blade.php; your app receives a rendered copy. Do not edit the package file — re-run the installer to pick up changes.
• Blade rendering matters. The guidelines are a Blade template. If you fork or override them, keep the Blade syntax valid; a rendering error can silently drop guidance from the AI context.
• Clear config cache after config changes. Run php artisan config:clear locally and php artisan config:cache in production. Agents often miss this and report stale package behavior.
• Publish selectively. Use the package’s documented publish tag (for example vendor:publish --tag=<package>-config) rather than publishing every asset, which can overwrite app customizations.
• Debug with version and generated files. If package behavior differs from the guidelines, check composer show <vendor>/<package> and whether the app’s generated guidelines are stale. The guidelines describe intent, not a runtime contract.
• Prefer public extension points. Use documented events, macros, or container bindings over subclassing internals. Register extensions in a service provider so AI-generated code stays on public APIs.
• Verify command names. After Boost install, confirm the exact artisan command names in the generated guidelines before scripting them. This is the most common failure mode when guidelines are missing.