Probe Laravel Package

Technical Evaluation

Architecture fit. Probe is a dev-only, in-process REST client and inspector that hooks into Laravel's route table, HTTP kernel, validation layer, and container. Architecturally it is a tooling package, not a runtime dependency: it wants require-dev, a non-production service provider, and no place in the deploy artifact. For teams already on Laravel 12 that is a clean fit; the package slots alongside Telescope, Debugbar, and Scribe rather than replacing them, though the overlap with all three is real and should be treated as a consolidation decision, not an additive one. The precompiled Svelte 5 SPA is the right call for consumers (no Node in the build pipeline, no Vite coupling), but it means the maintainer owns a build artifact that consumers cannot audit easily — treat the distributed assets as opaque third-party code.

Integration feasibility. Low-to-moderate. probe:install plus route/asset registration is a small change; the real work is organizational: environment gating, an authorization gate, and CI enforcement that the package never reaches production. Feature-by-feature feasibility:

Technical risk. Dominated by three items. (1) Environment leakage — a package that decrypts cookies, impersonates users, and relays destructive mutations is a critical incident if it is ever reachable in staging or production; the guard must be defense-in-depth (env check, config gate, Gate/can middleware, route disabled by default), not a single APP_DEBUG check. (2) False safety from dry run — engineers will infer "rolled back" means "no side effects," which is wrong for anything non-transactional; document this loudly and consider blocking dry run on endpoints that dispatch jobs. (3) Heuristic drift — auth and version detection are inferred, so wrong answers look authoritative in the UI; every inference needs a visible manual override and a "why did you think that" trace. Secondary risks: 0.1.0 on a Laravel version (13) that is not yet generally available implies a moving target and possibly unreleased dependency constraints; single-maintainer/bus-factor exposure on a package that touches security-sensitive internals; and no evidence yet of a security disclosure policy or a stated support matrix.

Key questions. Does the service provider hard-refuse to boot outside local/explicitly-configured environments, and can that guard be verified by test? Is there a documented authorization gate, or is registration alone the only control? Does the package phone home — is "telemetry" strictly in-process capture, and what does it write to disk, where, and for how long (cookie plaintext especially)? What are the rollback caveats for non-transactional side effects, and does the UI warn per-endpoint? What is the PHP/Laravel support policy and release cadence post-1.0? Who maintains it, what is the license, and is there a disclosure channel? How does route discovery behave with route:cache and with 500+ routes? Can version and auth inference be overridden per-route in config?

Integration Approach

Stack fit. Laravel 12-first, Laravel 13 forward-looking, PHP 8.2+ in practice. Fits teams on the standard stack with Sanctum, FormRequests, and Pest. Poor fit for apps relying on non-Laravel auth (custom JWT/OAuth gateways), heavy DDD route structures with non-obvious namespaces, or API surfaces documented exclusively via hand-written OpenAPI — Probe will infer something, but likely not your truth.

Migration path. There is nothing to migrate from; this is adoption, not replacement. Position it as a complement for the first two quarters: keep Telescope/Debugbar for runtime debugging and Scribe/Scramble for contract generation, and let Probe earn its place on the request-composition workflow. Only after the export output proves accurate against your existing OpenAPI spec should you consider retiring a doc tool.

Compatibility. Add as require-dev pinned to an exact version ("probe/probe": "0.1.0"), never a caret range, until 1.0. Enable auto-discovery only in local. Verify conflicts with Telescope, Debugbar, Ignition, and Horizon — all of them instrument the same kernel/query/log events, and duplicated listeners on large requests are a real memory concern. Check that the precompiled assets publish to public/vendor/probe and are excluded from production builds.

Sequencing.

1. Week 1 — sandbox. Install in one internal, non-customer-facing Laravel 12 service. Pin the version. Write the environment guard and a Gate authorization rule, and add a CI check that fails if the package appears in the production composer.lock.
2. Week 2 — evaluate discovery and auth. Inventory route coverage; record every route where version or auth inference is wrong, and confirm an override path exists in config.
3. Week 3 — dry run and profiling. Test dry run against an endpoint with jobs, mail, and external HTTP calls to calibrate expectations; measure memory/time on the largest response in the app.
4. Week 4 — export and test generation. Run probe:export to OpenAPI and diff against the existing spec. Generate five Pest tests from real requests; have a senior engineer critique them before any are merged.
5. Month 2 — decide. Expand to two more services, or hold if the guards or inference accuracy did not hold up. Re-evaluate at 1.0.

Operational Impact

Maintenance. Low direct maintenance for consumers (no Node toolchain, no build step), but non-trivial governance maintenance: a pinned version, a quarterly upgrade review against each Laravel minor, and a standing rule that Probe stays out of production. The dependency itself carries maintainer concentration risk — assume you may have to vendor or drop it, and keep the config file small so removal is a one-commit operation.

Support. Expect the first-line support burden to land on platform engineering, not the vendor: "why does Probe show the wrong auth badge," "why didn't dry run undo this." Budget a short internal runbook covering the environment guard, dry-run limits, and the override mechanism. Clarify the vendor's support channel and disclosure policy before expanding beyond the pilot.

Scaling. Per-developer, so headcount scaling is linear and cheap. The risks are app-side: query/log/cookie capture on high-traffic endpoints or large payloads will inflate memory in the dev container, and route discovery on a 500+ route app may add noticeable boot time. In-process dispatch scales fine for interactive exploration but is unsuitable as a load or concurrency test harness — it serializes through one process. The Pest generator scales well only if generated tests survive review; otherwise it produces a growing pile of brittle, unowned tests.

Failure modes. (1) Package reachable in staging/production → credential and session exposure, worst case. (2) Dry run treated as a sandbox → duplicate side effects in shared dev/staging databases. (3) In-process dispatch mistaken for real HTTP → auth, CORS, middleware-order, and proxy bugs pass exploration and fail in deployment. (4) Heuristic misdetection of version or auth → engineers test the wrong surface with false confidence. (5) Profiler capture on a large response → OOM in the dev container. (6) Precompiled SPA assets go stale or unpatched relative to the installed PHP package during partial upgrades. (7) Single-maintainer abandonment → forced migration under time pressure.

Ramp-up. Roughly half a day for a Laravel-fluent engineer: the UI is conventional (command palette, JSON editor, keyboard shortcuts), and the mental model maps to Postman/Insomnia. The learning that actually takes time is not the UI but the trust boundaries — which inference to believe, when dry run lies, and why in-process dispatch is not the same as a real request. Encode that in the runbook and in onboarding, not in tribal knowledge.