Project Boost Laravel Laravel Package

Technical Evaluation

Architecture fit. project-boost-laravel is developer tooling, not application code. It sits in require-dev, exposes a project-boost:sync Artisan command, and materialises laravel/boost's AI-assistant guidance (guidelines, Tools, search-docs, record-rule, Skills Activation) into a project's repository so that coding agents receive consistent instructions. For a TPM this is a low-blast-radius decision: it touches the developer experience layer and the repo's committed guidance files, not request handling, persistence, or deployment. It fits teams already standardising on Laravel Boost and wanting that guidance portable, version-pinned, and reviewable in pull requests.

Integration feasibility. Straightforward. Add the package as a dev dependency, run the sync command once to baseline the generated output, commit the diff, and optionally add a mcp config value. The 1.6.0 release adds PROJECT_BOOST_MCP (default true) so teams not using Boost's MCP server tooling can suppress that guidance block. Realistically an afternoon of pilot work on one repository, assuming Laravel/PHP version constraints check out.

Technical risk. Low-to-moderate, and concentrated in one place: upstream coupling. Every fix in 1.6.0 is the same class of defect — project-boost:sync silently omitting sections of laravel/boost's guidance (Tools, search-docs, record-rule, Skills Activation). Nothing crashes; the generated files simply look complete while missing content, which is the worst failure shape for AI guidance because nobody notices until agent behaviour degrades. Treat this package as a thin adapter that must track laravel/boost releases, and pin both versions together.

Key questions.

• Which laravel/boost versions is 1.6.0 verified against, and what is the supported range?
• Is project-boost:sync idempotent, and does it overwrite or merge hand-edited guidance files?
• Do existing installations need to re-publish the config file to gain the mcp key, or is it read from env with a default?
• Which editors/agents are targeted by the generated output (Claude Code, Cursor, Copilot, others)?
• Is the default true for PROJECT_BOOST_MCP a behavioural change for teams that have already published a config from 1.5.x?
• What is the maintainer cadence and bus factor (single-maintainer GitHub project vs. backed)?
• License terms and whether committed guidance files are acceptable to the org's IP/security policy.

Integration Approach

Stack fit. Laravel 11/12-style Artisan-command tooling with a publishable config and env-var overrides — idiomatic and familiar to any Laravel team. No service dependencies, no runtime hooks, no queue or cache interactions. It composes cleanly with an existing CI pipeline that already runs composer install and lints committed files.

Migration path. Pilot on a single active repository: install as dev dependency with laravel/boost pinned, publish the config, run project-boost:sync, and commit the baseline output as a standalone "guidance baseline" PR so reviewers can see exactly what content is being introduced. Once accepted, roll to a second repository to confirm the output is consistent and the config surface is sufficient before broad rollout.

Compatibility. The meaningful compatibility axis is laravel/boost version, not Laravel version — the adapter's whole job is mirroring upstream content, and 1.6.0's fixes prove that mirroring can lag. Pin laravel/boost to an explicit version in each repo rather than floating, and treat a laravel/boost bump as requiring a re-run of sync plus a diff review. For the new mcp key, verify whether config re-publish is required; if so, sequence it as a deliberate config-merge step rather than letting each developer discover the mismatch.

Sequencing.

1. Confirm compatibility matrix and licence with the maintainer/docs.
2. Pilot install and baseline commit on one repo.
3. Add a CI guard (see Operational Impact) that asserts expected guidance sections are present in generated output.
4. Merge config for PROJECT_BOOST_MCP where MCP tooling is not in use.
5. Roll out repo-by-repo with a shared template; document the upgrade ritual ("bump laravel/boost → re-sync → review diff").

Operational Impact

Maintenance. Low steady-state effort but a real, recurring obligation: every laravel/boost upgrade requires a re-sync and a human diff review. Assign an owner (typically a senior Laravel engineer or DevEx/platform). Budget a small recurring slice per quarter rather than a one-off setup cost. Re-publishing config on minor versions is the most likely routine chore.

Support. No production incidents are possible from this package, but it creates a new developer-support surface: "the agent gave bad advice / didn't know about our rules." Route those to the guidance owner, not to application support. Worth documenting explicitly so it doesn't land on on-call.

Scaling. Scales well across many repositories because the mechanism is a committed file plus a command. At scale, avoid per-repo hand-tuning: keep one shared baseline, use env vars (PROJECT_BOOST_MCP) for the only known variance, and accept that drift between repos is the main long-term cost. For monorepos, decide up front whether sync runs at the root or per-app.

Failure modes.

• Silent omission — the 1.6.0 bug class: sync drops guidance sections without erroring. Mitigate with a CI assertion on expected section headings/markers rather than trusting a clean exit code.
• Upstream version skew — laravel/boost moves, adapter lags, generated guidance becomes stale or partial. Mitigate with paired version pins.
• Overwrite of local customisation — if sync regenerates rather than merges, hand-edited guidance is lost. Confirm behaviour before rollout.
• Config key drift — published 1.5.x configs lack mcp; teams expecting the opt-out won't get it. Mitigate with a documented config-merge step on upgrade.
• CI masking — a scheduled sync job that auto-commits hides regressions. Prefer a check-only mode in CI and human-driven sync locally.

Ramp-up. Very low: one pilot afternoon, a short internal note on the upgrade ritual, and roughly one sprint before multi-repo adoption is routine. The 1.6.0 release is a net positive — it fixes real correctness gaps and adds a useful escape hatch — with no breaking changes, no deprecations, and no migration required for existing users beyond verifying whether they need to re-publish config to access PROJECT_BOOST_MCP.