Intercept Support Laravel Package

Technical Evaluation

promptphp/intercept-support v1.1.1 is a patch release of a read-only subtree split published from the promptphp/intercept monorepo at commit 73ed9bb731d9b793173dba33cf4a96cce8c8d5ea. This is the same distribution pattern Laravel uses for illuminate/* components: the package is installable via Composer but is not the system of record for the code.

Architecture fit. A "support" package in a Laravel ecosystem conventionally carries shared contracts, DTOs, config objects, helpers, and service-provider wiring consumed by the main package. Expect it to be a transitive dependency of promptphp/intercept rather than something an application requires directly. Architecturally this is low-friction: it slots into an existing Laravel app with no host-application changes, and if it holds only interfaces/value objects it imposes no meaningful coupling. The vendor naming (promptphp) suggests an LLM/prompt-interception domain, which means the package likely sits in a request path — worth confirming whether it ships runtime middleware or only abstractions.

Integration feasibility. Install is standard composer require. The release note contains no version constraints, no changelog, and no Laravel/PHP support matrix, so feasibility must be verified from composer.json rather than from the release metadata. The provenance hash is useful for auditability but does not tell us what changed.

Technical risk. Low-to-moderate. A patch bump carries no implicit breaking-change signal, but three risks are structural, not version-specific:

• Split skew — the published tag and the monorepo source can drift if split automation fails; the commit hash is the only way to reconcile.
• Silent transitive upgrade — because it is likely pulled in by the parent package, a composer update can move this package without an explicit decision.
• Opaque change surface — v1.1.1's actual diff is unreviewable from the notes alone.

Key questions.

1. What changed between v1.1.0 and v1.1.1, and is there a changelog or GitHub Releases feed on the monorepo?
2. Is intercept-support required directly or only transitively, and are its version constraints lockstep with promptphp/intercept?
3. What is the supported PHP/Laravel matrix, and does the package register a service provider or publish config?
4. Does it execute any runtime code in the request path, or is it contracts/helpers only?
5. What is the license, security disclosure policy, and CI/test status on the source commit?

Integration Approach

Stack fit. Assumes a Composer-based Laravel application (Laravel 10/11-era conventions). Because this is a support layer, integration effort is near-zero for the consuming app — the real question is whether the parent package's constraints resolve cleanly against the app's pinned Laravel version.

Migration path. There is nothing to migrate from. The realistic paths are:

• Transitive adoption (default): let promptphp/intercept pull it in; do not add an explicit requirement.
• Explicit pin: if the app touches its contracts directly, require it explicitly with a caret constraint so contract changes surface in review.

Compatibility. Confirm three things before merging a dependency bump: (a) the illuminate/* / php constraints in the package's composer.json, (b) whether the parent package's constraint on this package is compatible with the app's lock file, and (c) whether the patch touches any published config or interface signatures that application code implements.

Sequencing.

1. Read composer.json at the referenced source commit — constraints, autoload, providers.
2. Diff v1.1.0 → v1.1.1 in the monorepo (not the split) to establish actual change content.
3. Bump in a branch, run the app's test suite plus any interception-path integration tests.
4. Promote to staging with the parent package upgraded in the same change set.
5. Pin in composer.lock and record the source commit hash in the dependency review note.

Governance note. Do not fork or patch the split repository. Any fix must go upstream to promptphp/intercept; app-local patches will be silently overwritten by the next split publication.

Operational Impact

Maintenance. Maintenance burden is low but the ownership model is unusual: the split is read-only, so the team cannot self-serve fixes. Upgrades arrive bundled with the parent package's release cadence, which means this package's release notes will rarely carry standalone planning value — track the monorepo, not this feed.

Support. Issues should be filed against promptphp/intercept. If the monorepo is a single-maintainer project, bus factor is the dominant operational risk. Establish an internal fallback: if the package is abandoned, the app either pins the last good version or the support layer is thin enough to vendor locally.

Scaling. A support/contracts package should be effectively free at runtime — no measurable overhead in the request path. The scaling concern is not throughput; it is version sprawl across multiple services consuming different pins of the same parent package.

Failure modes.

• Split automation fails → tag published without matching source, or source published without tag.
• Parent package bumps its constraint on this package → forced upgrade on next composer update.
• Interface change lands in a patch release → application implementations break despite semver expectations (the classic support-package failure).
• Abandonment or repo archival → no security patches, no Laravel major-version support.

Ramp-up. Fast for any Laravel developer — conventional package shape, standard Composer install. The only non-obvious concept is the subtree-split workflow, which engineers must understand before debugging "why is this code read-only?"

Recommendation. Adopt v1.1.1 as a routine patch, consumed transitively and locked. Do not treat these release notes as the basis for a decision — pull the monorepo diff at 73ed9bb and the package's composer.json before signing off, and register promptphp/intercept (not this split) as the watch target for future assessment updates.