Laravel Livewire Boost Laravel Package

Getting Started

This release is a maintenance/minor feature bump, not a rewrite — existing installs keep working. The practical entry points:

1. Check the new requirements matrix in the README first. v1.0.1 explicitly documents supported PHP/Laravel versions and the Laravel Boost compatibility range. Read that before composer require, especially if you are on Laravel 10 or Boost 1.x — this release targets Boost 2.x, so a mixed-version team needs to align before upgrading.
2. Install and publish:

   composer require <vendor>/<package>
   php artisan vendor:publish --tag=<package>-config
   

   The published config is where the planning-guide output path lives — see the Gotchas section, since this release changed behaviour there.
3. Generate your first guide. The canonical first use case is: pick a feature you're about to build, run the package's generator command, and get a structured planning document (scope, tasks, acceptance criteria) that you can hand to your AI agent or use as a PR checklist.

If you use Laravel Boost, the intended flow is that Boost's MCP tooling can read the generated guide, so the agent plans against your repo's conventions rather than guessing. Verify the tool is registered after install (php artisan boost:status or the Boost panel) before assuming the integration is live.

Implementation Patterns

Plan-before-code loop. The most common day-to-day pattern: generate a guide at the start of a ticket, commit it, implement against it, then archive it. Keeps AI-assisted work auditable and gives reviewers a spec to diff against.

Per-feature directories. Rather than a single overwritten file, drive the output path from config (or a --path/--name flag if available) so each feature gets plans/{ticket-id}-{slug}.md. This is exactly the area the 1.0.1 path fix touches, so re-check your config after upgrading.

Boost-fed context. Register the generated guide directory with Boost's MCP server so agents can pull the active plan. Typical wiring is a path entry in boost.json / the Boost config pointing at your plans directory. Once wired, the workflow becomes: agent reads plan → proposes edits → you review against acceptance criteria in the same plan.

Template customisation. Publish the package's stubs/views and edit them to match your team's definition-of-done. This is the main extension point — most teams end up adding sections for "migration impact", "feature flag name", or "rollback plan" to the default template.

CI freshness check. If guides are committed, add a lightweight CI step that fails when a PR touches app/ without touching the corresponding plan. Cheap way to keep the practice from rotting.

Config-as-code. Commit the published config with an explicit output path so every developer and CI runner generates to the same location. Don't rely on the package default — that's the value that changed in this release.

Gotchas and Tips

• The path fix is the one thing to actively verify. v1.0.1 corrects the generated planning-guide path. If you installed 1.0.0 and hand-patched or worked around a wrong location, re-publish the config (vendor:publish --force) and diff it — otherwise you'll keep the old, incorrect value.
• Clear caches after upgrading. php artisan config:clear && php artisan view:clear. Stale cached config is the single most common reason a path or template change "doesn't take effect".
• Boost 2.x is the supported line. If your app is still on Boost 1.x, pin the package to the previous version rather than upgrading and debugging MCP registration failures. Add an explicit constraint in composer.json so a composer update doesn't silently cross the boundary.
• Path semantics matter. Output paths are usually resolved relative to the app base path, not storage_path. If guides land somewhere unexpected after the upgrade, log the resolved absolute path rather than guessing from the config string.
• Generators overwrite. Assume regeneration replaces the file. Either keep guides in VCS so you can diff/recover, or be deliberate about a --force flag. Losing a hand-edited plan is the classic first-week mistake.
• The README banner is cosmetic; the requirements block under it is not. Treat that section as the source of truth for PHP/Laravel/Boost versions when triaging install issues.
• Debugging integration issues: confirm the command is registered (php artisan list | grep <package>), then confirm the output path resolves, then confirm Boost can see the directory. Those three checks cover most failure reports.
• Extension points to prefer: published config, published stubs/views, and the generator command's options. Avoid editing files under vendor/ — this package is clearly still shipping fixes, and v1.0.1 proves patch releases will move things.