Probe Laravel Package

Product Decisions This Supports

API surface visibility as a first-class product concern. Probe's zero-config route discovery and multi-strategy version detection turn Laravel's route registry into an explorable, versioned catalog. For PMs, this is a fast, factual answer to "what API surface do we actually ship, and how is it versioned?" — useful for roadmap grooming, deprecation planning, and evaluating whether a version-bump strategy (URI prefix vs. route name vs. middleware) is applied consistently across the codebase. Inconsistent versioning is a product risk, not just a code smell, because it directly affects customer migration cost.

Contract clarity before customer commitments. Validation-rule reflection (FormRequests, inline validate(), Spatie Laravel Data) with faker-derived examples means the request schema can be demonstrated to design, docs, support, and sales-engineering without waiting on hand-written API docs. That compresses the loop between "we plan to ship this field" and "here's a realistic example of what a customer will send." It supports build-vs-buy decisions too: what a competitor's documented API offers is easy to compare against your real, reflected schema rather than a stale wiki.

Safe exploratory testing of destructive operations. Dry Run mode with automatic transaction rollback is the feature that changes a PM's behavior, not just engineering's. It lowers the cost of answering "what happens if a customer does this?" for POST/PUT/DELETE flows, and it lets non-engineers (product, QA, support) exercise admin and billing mutations against a local environment without permanent damage. That has direct value in incident postmortems and in reproducing support tickets.

Persona and auth parity. Visual auth badges plus one-click Sanctum impersonation support a product-relevant question: does a feature behave correctly for an anonymous user, a basic-auth client, an API-key integration, and a session user? Multi-persona coverage is a common gap in early-stage Laravel products, and Probe makes it cheap to demo to stakeholders in a review.

Observability during reviews and triage. The telemetry and cookie profiler (SQL queries with timings, logs, dumps, decrypted cookies) supports performance-related roadmap decisions — "is this endpoint slow because of N+1 queries or because of the network?" — and shortens the path from a support report to a concrete, explainable cause.

Turn exploration into durable regression coverage. The one-click Pest test generator is the highest-leverage PM-adjacent feature: it converts an exploratory request into an idiomatic feature test, which is exactly the artifact that defends a shipped behavior across future releases. PMs can push for "every new endpoint gets a generated test at review time" as a lightweight team norm, which reduces regression risk without a dedicated QA investment.

Export as a stakeholder communication channel. probe:export to OpenAPI / Postman / Scribe, and probe:scribe-sync, mean the same source of truth can feed docs sites, partner integration kits, and internal collections. That matters for packaging decisions (self-serve docs vs. gated partner docs), for onboarding metrics, and for supporting an external developer audience without a separate documentation effort.

When to Consider This Package

Adopt when:

• The product is a Laravel 12/13 application with a meaningful internal or external API surface and multiple route versions or consumer personas.
• API documentation is currently manual, stale, or nonexistent, and the team wants reflection-driven output rather than writing annotations by hand.
• The team is small enough that a dev-only, in-app explorer offsets real time cost — particularly where support/QA/product need to reproduce issues without a dedicated staging toolchain.
• You want generated Pest feature tests as a side effect of exploratory testing, and would otherwise not budget for it.
• You need exportable API artifacts (OpenAPI, Postman, Scribe) to feed docs or partner integrations.
• You're making versioning or deprecation decisions and want evidence about how versioning is actually implemented across controllers, middleware, and routes.

Look elsewhere or defer when:

• The app is not Laravel 12/13, or is a polyglot/microservices estate where the routes live outside Laravel — the discovery value collapses.
• Production safety posture is immature. Probe is explicitly dev-only; it must be gated out of production by environment and configuration. If you cannot guarantee that guardrail, do not adopt.
• You need enterprise contract testing, load testing, or a spec-first workflow with governance (e.g., OpenAPI-first with CI schema linting). Probe generates specs from code; it is not a design-first spec authority.
• The API is trivially small (a handful of endpoints) such that a hand-maintained Postman collection is cheaper than adding a dependency and a dev tool surface.
• You require a mature, long-lived package with a versioning and support history. This is v0.1.0 — treat it as early, expect churn, and pin it.
• Frontend framework flexibility is required and the Svelte 5 SPA bundle's zero-node-dependency promise conflicts with your asset pipeline or CSP rules; validate that its asset delivery fits your setup.

Migration and adoption risk to note:

• probe:install will publish configuration, routes, and assets into the host app. Budget a review of what it writes, and confirm the explorer routes are environment-gated.
• The in-process dispatch via the HTTP Kernel is a meaningful architectural choice (avoids artisan serve worker deadlocks). Confirm it behaves correctly behind your local server of choice (Sail, Herd, Valet, Octane) before relying on it in demos.
• Dry Run's transaction rollback is only as safe as your database and code: side effects that escape the transaction (queued jobs, external API calls, file writes, cache, mail) will not roll back. Do not treat Dry Run as a substitute for environment isolation.

How to Pitch It (Stakeholders)

One line for executives: Probe is a free, dev-only inspector that makes our Laravel API surface inspectable, demonstrable, and testable in minutes — it reduces the time between "we think the API does X" and "here is proof the API does X," and it emits documentation and regression tests as a byproduct.

For engineering leadership: it is a developer-experience and correctness tool, not a runtime dependency. It discovers routes with zero configuration, reflects real validation rules into example payloads, safely exercises destructive endpoints with transactional rollback, and converts exploratory calls into Pest feature tests. Route and asset exposure is environment-gated, and it ships as a dev-only tool. Cost is a package dependency plus a small setup review; risk is contained by pinning v0.1.0 and keeping it out of production.

For product, design, and support: it removes the dependency on engineering to answer routine API questions. You can browse every endpoint by version and resource, see exactly which auth each route requires, preview realistic request payloads, and inspect what the server actually did — SQL, logs, cookies — when a request misbehaves. That shortens triage and makes API reviews concrete rather than aspirational.

For partner-facing and docs stakeholders: probe:export and probe:scribe-sync let us generate OpenAPI, Postman, and Scribe collections from the running application, so partner integration docs and internal collections can track the real API rather than drifting from it. This is a meaningful reduction in documentation maintenance cost, though it should be validated against our publishing workflow before we commit.

Recommended next step and framing: run a scoped, time-boxed pilot on one API version and one internal team. Success criteria: setup completed with routes correctly environment-gated; all routes in the target version discovered with accurate verbs and auth badges; generated tests passing in CI; exported OpenAPI matching reviewed expectations. If the pilot holds against Laravel 12/13 and our chosen local server, position Probe as a standard dev-tooling addition and a contributor to our API documentation pipeline. Communicate it internally as early-stage (v0.1.0) and developer-only, with an explicit expectation of API churn and a pinned version.