Verify Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Laravel adapter over indexnowkit/core: service-provider bindings, publishable config, an artisan check command, a queued verification/submission job, and a PSR-16-backed RobotsCache on top of the framework cache. That is the right shape for this kind of package — framework glue in the adapter, crawler/verification semantics in core — and 0.4.0 moves further in that direction.
• The headline change is an architectural correction: pre-flight verification now always uses the PSR-18 client the core discovers, built with max_redirects: 0 and verify.timeout, instead of whatever the application bound as http.client. PSR-18 has no mechanism to forbid redirect-following on a caller-supplied client, so a redirect-following client would surface the final 200 and silently neuter verify.redirect, verify.max_redirects, the redirect-target host check and loop detection. Verification is a crawler simulation; it needs a transport whose behaviour it controls. This is the correct boundary, and it is a meaningful correctness win.
• The cost is that the adapter's two HTTP paths now diverge explicitly: verification uses the core-built client, submissions still honour http.client (so proxies and instrumented clients keep working where they matter for actual POSTs). That is a defensible split, but it is a mental model users must be taught, and the verify.transport line of check graduating from warning to informational is the right affordance for that.

Integration feasibility

• Mechanically trivial: a composer bump to the adapter release carrying indexnowkit/core ^0.13, no config migration implied by the notes, no database or route changes.
• The real integration work is auditing assumptions:
  • Any application that bound or overrode http.client expecting pre-flight traffic to flow through it (corporate egress proxy, mTLS, instrumented/logging client, VCR-style recorder) loses that for verification. The app server must be able to reach verification targets directly, or the pre-flight will now fail where it previously "succeeded".
  • Test suites that fake the HTTP client to stub verification responses will now hit the real network. This is the most likely source of red builds and should be checked before scheduling the upgrade.
  • VerifyServices::package() is now a delegator to OptionalPackage::verify(); callers should move to the core API directly.

Technical risk

• Behaviour change on a 0.x minor. Semver permits it, but the practical effect is that verification results are not comparable across the upgrade: any prior run where a redirect-following client was bound may have under-reported redirect problems. If verify outcomes feed reporting, allow-lists or customer-facing status, treat pre-upgrade history as suspect rather than as a baseline.
• Dependency bump to indexnowkit/core ^0.13 brings whatever else changed in core; the notes only cover the adapter-visible delta. Confirm there are no other public-surface changes before committing to the version.
• Two fixes increase the set of URLs that pass verification (relative canonical against <base href>) and change queue timing (time_budget taken before verify.delay). Individually benign; together they change throughput and submission volume, which is a capacity question rather than a correctness one.
• The RobotsCache::key() IPv6 fix (stripping [, ], :) is a strict improvement — a PSR-16-compliant store previously rejected the key and the class degraded to one robots fetch per process. Expect fewer robots fetches and more cache entries, i.e. lower load and slightly different cache-key shapes.

Key questions

1. Is there a supported way to retain a proxy or custom CA bundle for pre-flight now that http.client is ignored — e.g. configuring the core's client discovery, or a dedicated binding? If not, that is a capability regression for locked-down networks and should be documented as such.
2. Is VerifyServices::package() formally deprecated, with a stated removal version, or merely "preferred not to call"?
3. What else ships in core 0.13.0, and does it alter config keys, exception types or command output that operators script against?
4. Has http.client been removed from the published config/docs, or is it still documented for pre-flight where it now has no effect? Stale docs here will generate support load.
5. How should verification be stubbed in tests now — is there a container seam for the core-built PSR-18 client?
6. Does the core-built verification client reuse connections, or is one constructed per verify? Relevant at high URL volumes.
7. How much does the <base> canonical fix move expected submission volume on a representative site?

Integration Approach

Stack fit

• Standard Laravel package install: composer, service provider auto-discovery, vendor:publish for config, one artisan command, one queue job. No framework-version friction is implied by the notes; confirm PHP constraint from core 0.13.
• PSR-18 client discovery effectively adds an implicit runtime dependency (a discoverable PSR-18 implementation plus php-http/discovery wiring). Since that client is now the only verification transport, "works on my machine" is no longer rescued by an app-supplied client — treat the discovered client as a first-class deployment prerequisite.

Migration path

1. Bump the adapter (and therefore core to ^0.13); resolve conflicts if the app pins an older core transitively.
2. Grep for VerifyServices::package( and switch call sites to OptionalPackage::verify().
3. Grep for http.client bindings, overrides and container decorations; classify each as submission-path (keep) or verification-path (no longer effective).
4. Fix tests that fake the client for verification — either stub at the new seam or move those cases to integration tests against a controlled endpoint.
5. Clear and rebuild config cache, restart queue workers (container bindings and cached config both matter here).
6. Run check against a representative URL set and read the new verify.transport line to confirm which client does what.

Compatibility

• Pre-1.0 package; minor bumps can carry behaviour changes like this one. Pin exact versions if verify behaviour is load-bearing for downstream reporting, and read core's changelog as part of every adapter bump from here on.
• No config-format change is signalled, so existing published config files should keep working; the risk is documentation drift around http.client, not schema drift.

Sequencing

1. Staging upgrade and egress check — can the app server reach verification targets without the corporate proxy?
2. Differential run: same URL set on old and new versions. Expect (a) previously-dropped pages with <base href> now passing canonical, (b) redirecting URLs now correctly failing rather than silently passing. Both are wins; both look like "the upgrade broke something" if not anticipated.
3. Adjust job batch size / verify.delay / visibility timeout if per-job throughput moved.
4. Roll to production on one site or a narrow URL subset first, watching submission volume and verify error rates, then widen.

Operational Impact

Maintenance

• Low absolute maintenance: most logic lives in core, so the adapter surface stays small. The trade is a second changelog to track — adapter bumps now have a habit of importing core behaviour changes, and this release is the template for that.
• One small piece of API drift to retire (VerifyServices::package()), with no urgency implied.

Support

• The verify.transport line becoming informational is a genuine support win: it answers "which client did what" in one line of check output instead of a bisect.
• Expect two predictable ticket classes. First, "pre-flight started failing after upgrade" from anyone behind an egress proxy — this is a firewall/architecture conversation, not a bug. Second, "why are more URLs being submitted" from the <base> canonical fix.
• Document the two-client model (verification client vs submission client) in the package docs and in any internal runbook; it is the one concept users must internalise from this release.

Scaling

• Verification no longer inherits the app client's timeouts, retries or connection pooling; verify.timeout is now the sole knob. Watch for per-verify client construction — no keep-alive means more TLS handshakes at volume, so measure before scaling URL batches.
• time_budget being taken before verify.delay waits is the right fix for fitting inside a queue visibility timeout, but it reduces the work a job can complete within a given budget when a delay is configured. Re-check batch sizes and job timeout against real latency; a job that previously finished now may not.
• The IPv6 cache-key fix removes the per-process robots refetch degradation, which is a straightforward load reduction on strict PSR-16 stores and on IPv6/local setups.

Failure modes

• Hard failure: no direct egress from the app server or a missing/misconfigured PSR-18 implementation — verification errors where the app-supplied client previously masked the problem.
• Silent divergence: TLS/CA trust differences between the app's client and the core-discovered client, surfacing as pre-flight failures that look site-specific but are environmental.
• Volume: more pages passing verification plus delays consuming budget changes the submission curve; quota or rate-limit pressure against the submission endpoint is the downstream effect.
• Cache hygiene: new key shapes for IPv6 hosts mean old entries simply miss; no action needed beyond awareness.

Ramp-up

• Small for a competent Laravel team: one composer bump, one command, one config file. Call it half a day for a straightforward app, one to two days where tests fake the HTTP client or egress is proxied — those are the two places this release actually costs time.
• The learning curve is conceptual, not technical: verification is a controlled crawler simulation and must not be routed through an arbitrary application client. Teams that internalise that will read the check output correctly from day one.