Dev Log: 2026-08-06 — Pest 5 everywhere, a build-preset registry, and an MCP server inside a Laravel app

TL;DR

• Rolled a Laravel starter/scaffolder onto Pest 5, made pest --tia (test impact analysis) the default, and added laravel/doctor to generated projects.
• On a deployment platform: a build-preset registry — one interface, many runtimes (Laravel, Django, Go, Next.js, static…) — plus provider parity so Swarm and Kubernetes sit behind the same driver contract.
• On a CRM app: stood up an MCP server inside the app so an AI assistant can call real domain tools (contacts, pipeline, tasks) over a governed endpoint.
• Plus an incident write-up on a portal project: a Single-ID / PostgreSQL dependency finding, documented for the client.

Busy day across a few repos. The three standouts each got their own focused post; quick tour here.

Pest 5 as the default, not a chore

The starter tool now ships Pest 5 and — the part I actually care about — runs pest --tia by default, so composer test only re-runs the tests your change touched. The upgrade dragged in the usual chain: PHP 8.4 floor, Symfony Console 8 (where add() is gone, you call addCommand()), and a sneaky one — a Redis throttle that leaked state across test runs and threw random 429s until it was guarded to non-testing environments. Full breakdown in the focused post.

One interface, many runtimes

The deployment platform learned to build lots of app types — Laravel, Django, Go, Node, Next.js, static sites — without a match statement growing to the size of a small country. The shape is a preset contract plus a registry: each runtime is a small class that knows how to build itself, and the registry resolves the right one. Same story for infra: a driver contract lets Swarm and Kubernetes back the same operations, so the platform code doesn't care which is underneath. That's the driver-based abstraction pattern doing exactly what it's for.

An MCP server living inside the app

The CRM now exposes an MCP server — the app itself is the tool provider. Instead of an assistant guessing at your database, it calls named, authorised tools (list_contacts, pipeline_summary, my_tasks_today…) that run through the same policies and validation as the UI. The interesting design bit is a small Tool base class plus a server that "takes over" one endpoint, so every tool is testable in isolation. Focused post digs into the structure.

The unglamorous but important one

A portal project got a documented incident finding: a Single-ID dependency on PostgreSQL with a client-facing brief and feedback applied. No code fireworks — just the discipline of writing down why a system behaves the way it does before it bites someone at 2am.

What's next

Put the build-preset registry and the MCP tools under proper Pest suites, and let TIA earn its keep on the bigger repos where the full run actually hurts.