Probe Laravel Package

Technical Evaluation

Architecture fit. morcen/probe is a Laravel package in the 0.0.x line. At this version, expect the conventional shape: a service provider (likely auto-discovered), a config file, and either a facade, artisan commands, or HTTP routes depending on whether it probes application health, queries, or environment state. Architecturally, that places it in the observability/ops lane rather than the request path — the favourable case. If it registers middleware or a public route, it moves into the hot path and the risk profile changes materially.

Integration feasibility. Mechanically simple: composer require morcen/probe and a config publish. The real feasibility question is the compatibility matrix, which the release note does not state. Unknowns that gate a composer require: supported Laravel majors, minimum PHP, whether it ships migrations, and whether it depends on anything with a wide version range.

Technical risk. High, and concentrated in process rather than code quality:

• Pre-1.0 semver. The 0.0.x segment means every release is potentially breaking, including patches. ^0.0.5 in Composer resolves only within >=0.0.5 <0.0.6, so upgrades are manual by design — treat this as an explicit pin, not a constraint.
• Release note carries no signal. The v0.0.5 note is a bare compare link (v0.0.3...v0.0.5). There is no feature list, no breaking-change declaration, no migration guidance. This is the single most important fact in this assessment: it is not evidence of a small release, it is absence of evidence.
• Gap at v0.0.4. The diff spans 0.0.3 → 0.0.5, implying 0.0.4 existed at some point. Verify whether that tag was withdrawn or re-pointed; a yanked tag is a supply-chain and stability signal worth reading the commit history for.
• Single-maintainer / low-traffic project. Low download counts and one maintainer mean the bus factor is one and security review is effectively yours. Do not assume a CVE feed will cover it.

Key questions for the maintainer (or for your own source review):

1. What changed between 0.0.3 and 0.0.5 — and was 0.0.4 withdrawn, and why?
2. Which Laravel and PHP versions are tested in CI, and is there a matrix file to prove it?
3. Does it register HTTP routes, middleware, or a scheduled task? If routes, what is the default exposure and is there an auth guard?
4. Does it persist anything (tables, cache keys, log channels) and does it ship a migration?
5. Is there any overlap with Laravel Pulse, Telescope, or Horizon — i.e. does this duplicate a first-party tool you already run?
6. Does the service provider do work at boot (I/O, network, container resolution)? Boot-time failures in Laravel are app-wide failures.

Integration Approach

Stack fit. Reasonable if it is a diagnostics package and if you have no first-party equivalent. Laravel Pulse (health/usage) and Telescope (request introspection) are officially maintained and cover adjacent ground. Before integrating, establish the differential: what does probe expose that Pulse does not? If the answer is thin, the correct decision is to not integrate — the package's value has to exceed the cost of carrying a pinned, undocumented, pre-1.0 dependency.

Migration path. There is no migration path; there is an adoption path. This is greenfield: nothing to move off, nothing to backfill. Scope it as a time-boxed spike on a throwaway branch, not a scheduled integration.

Compatibility. Two hard gates:

• Confirm the Laravel/PHP support window against your runtime before writing any code. If your app is on a Laravel major not covered, stop here.
• Pin exactly (0.0.5, no caret) and commit composer.lock. Record the pin and the rationale in your dependency register so the next upgrade is a deliberate task rather than an accident.

Sequencing.

1. Source read (half a day). Skim the provider, config, and any routes. This substitutes for the missing changelog and is non-negotiable at 0.0.x.
2. Spike branch. Install pinned, publish config, exercise the package's primary surface in isolation.
3. Isolation. Gate behind an env flag and, if it exposes routes, behind auth and non-production routing. Assume default exposure is unsafe until proven otherwise.
4. Shadow period. Run in staging for one release cycle. Watch boot time, log volume, and any new storage growth.
5. Go/no-go. Decide against written criteria: documented behaviour, maintained cadence, no overlap with first-party tooling, and a named internal owner.

Do not sequence this in parallel with an unrelated infrastructure change — at this maturity you want a clean signal if something breaks.

Operational Impact

Maintenance. You are the maintenance plan. Expect to read source diffs on every upgrade because the changelog will not tell you what changed. Budget a recurring line item — even a small one — for "review probe releases," and accept that the honest long-term position is often to fork or vendor the small surface you actually use if the package stalls.

Support. Effectively none at this tier: no vendor, no SLA, no guaranteed issue triage. Internal ownership must be explicit and named, not "the platform team." If it becomes load-bearing (e.g. wired into alerting or readiness probes), escalate it to a reviewed dependency with a documented exit path.

Scaling. Depends entirely on invocation model:

• On-demand (artisan/route) — negligible; scale risk is limited to how often you call it.
• Scheduled — cost is fixed and predictable.
• Per-request middleware — the only genuinely dangerous case. Probe work on every request compounds with traffic; measure before and after.

If it performs outbound checks (DB, cache, HTTP), those become latency and failure-domain contributors to whatever calls it — and readiness endpoints that check dependencies are a classic source of cascading restarts.

Failure modes to design against.

1. Boot-time failure. A throwing service provider or unresolvable binding takes down the whole app, including routes unrelated to the package. Test a boot with the package's config absent and with dependencies unavailable.
2. Endpoint exposure. If it registers routes, an unauthenticated diagnostic endpoint leaks environment, versions, or connection details. Treat as a security finding until configured otherwise.
3. Unbounded writes. Probe output into logs, cache, or a table can grow without retention. Confirm where it writes and set a retention policy.
4. Silent behaviour change on upgrade. Because patches may break, an unpinned upgrade can alter probe semantics — a health check that starts returning unhealthy for a new reason is an outage trigger. Pin, and diff before bumping.
5. Abandonment. Package stops receiving updates and eventually blocks a Laravel major upgrade. Mitigation: keep the integration surface small enough to replace in a day.

Ramp-up. The learning curve is small — likely one config file and one or two commands — but the trust curve is steep because documentation is thin and the release history is opaque. Onboarding cost is not "how long to learn the API," it is "how long to read the source well enough to defend it in a review." Allocate that explicitly, and write a one-page internal note capturing what the package does, why it was chosen over Pulse, and how to remove it.

TPM recommendation. Treat v0.0.5 as a spike candidate, not an adoption. The release notes provide no basis for a production decision: no features, no breaking changes, no deprecations — only an unannotated diff across two patch versions with an apparent gap at 0.0.4. Approve a half-day spike on a pinned, feature-flagged branch in non-production; withhold production approval pending the six questions above, particularly the Laravel compatibility matrix and whether it exposes routes. If it duplicates Laravel Pulse, decline — the marginal value does not justify carrying an undocumented pre-1.0 dependency.