Statamic Boost Laravel Package

Technical Evaluation

Architecture fit

• chrisvasey/statamic-boost is a developer-experience / agent-context layer, not an application-runtime dependency. It augments Laravel Boost (with laravel/mcp ^1.0.1) with Statamic-aware AI guidelines, offline Statamic 5/6 documentation, fieldtype discovery, and Antlers examples, and manages the Boost configuration that wires those tools up.
• Coupling to our application code is shallow (service provider + installer command + generated artifacts), but coupling to three upstreams is high: Laravel Boost 2, laravel/mcp, and Statamic 5/6.
• Good fit for teams already standardized on Boost; near-zero value for teams not running an MCP-capable assistant.

Integration feasibility

• Standard Composer install; should be treated as require-dev. Verify whether the service provider self-registers and whether anything loads in production.
• The installer is the real integration point and it mutates existing Boost configuration. This release fixes Statamic-environment preservation and installer failure reporting, which confirms both failure classes existed. Treat the installer as a config-mutating migration, not a drop-in.
• CI now covers PHP 8.5 / Laravel 13 / Statamic 6 / Boost 2, but only on fresh install. Upgrade paths and mixed-version estates are not vendor-tested.

Technical risk

• Upstream pin drift (high likelihood / medium impact): the Boost config format and MCP API are the contract; every fix in 1.3.0 is "keep up with Boost/Statamic" work.
• Config clobbering (reduced, residual medium): environment preservation is now fixed and installer failures return correctly, but idempotency of the full install is unproven from release notes alone.
• Release-noise risk (high likelihood / low impact): weekly automated minor releases on documentation changes inflate upgrade cadence and defeat meaningful human review of version bumps.
• Doc staleness (inverse risk): docs are pinned to upstream sources with licenses attached, but freshness depends entirely on that automation. A lagging pipeline yields confidently wrong Antlers/fieldtype guidance.
• Bleeding-edge support matrix (PHP 8.5, Laravel 13, Statamic 6) may exceed what our production estate runs.
• Single-maintainer bus factor and unstated package license — verify before adoption.

Key questions

• Is this dev-only, and does it expose an MCP server or tools that could be reachable in production?
• Which (Laravel × Statamic × Boost × PHP) combinations are supported versus merely CI-tested?
• Is the installer idempotent, and does a re-run produce a clean or dirty git diff?
• Which generated artifacts get committed and reviewed in PRs?
• What is the doc-refresh SLA after an upstream Statamic release, and can docs be pinned to our Statamic minor?
• Package license, security disclosure process, maintainer continuity?
• Is the offline docs bundle complete, or is network access needed at install time?

Integration Approach

Stack fit — Laravel + Statamic monolith or multi-site, Composer-managed, Laravel Boost 2 already installed. Confirm PHP floor against our estate; 8.5 is CI-verified, not a requirement.

Migration path — no prior assessment exists, so this is first adoption, not migration. Run it as a pilot:

1. Upgrade Boost to 2 and laravel/mcp to ^1.0.1 in an isolated branch; confirm the app boots without the new package.
2. Install chrisvasey/statamic-boost:^1.3 as a dev dependency.
3. Run the installer, capture git diff before/after, and explicitly verify the Statamic environment value survives a Boost config rebuild (the specific 1.3.0 fix).
4. Exercise generated MCP tools on a real site: fieldtype discovery against a non-trivial fieldset, Antlers examples against actual templates.
5. Re-run the install to prove idempotency, then induce a bad config to confirm failures now surface instead of passing silently.
6. Only then template the change across additional repos.

Compatibility — pin ^1.3 with a committed lockfile. Statamic 4 and Boost 1 are out of scope; upgrade those first rather than running a mixed fleet during the pilot.

Sequencing — one pilot repo for 2–3 sprints, then a documented standard in the repo template, then wider rollout. Gate rollout on: generated-artifact churn being acceptable to reviewers, and an agreed version-pin policy for the weekly minors.

Operational Impact

Maintenance — two streams: our upgrade cadence and the vendor's weekly automated doc releases. Recommend Renovate/Dependabot grouping for this package with a monthly batch review rather than auto-merging minors — the version number no longer signals functional change. Budget a small recurring review.

Support — single-maintainer OSS, no SLA. Mitigation: the package is additive and removable (config plus generated guidelines), so keep a documented removal path. Do not let runbooks depend on generated guidance without a fallback.

Scaling — scales with repo count and headcount, not traffic. Two costs to watch: generated doc size inflating assistant context (token cost and latency per request), and per-repo config drift as teams run the installer independently.

Failure modes

• Installer overwrites Boost/Statamic config on re-run (partially addressed; verify).
• Boost/MCP version mismatch → Composer conflict or MCP tools failing at runtime with a weak signal.
• Docs pinned to a different Statamic version than ours → plausible-but-wrong guidance that reviewers may not catch.
• MCP surface unintentionally reachable outside dev.
• Floating version constraints pulling unexpected weekly minors into CI.
• Silent installer failure (1.3.0 surfaces return codes; still test the negative path).

Ramp-up — low for an individual developer (one command, roughly an hour). Non-trivial for the organization: MCP concept literacy, a security review of which tools are exposed and where they can run, and a written policy that generated guidelines are advisory and reviewed like any other code artifact. Estimate ~1 day of TPM/security time plus half a day per pilot developer before the rollout decision.