Pulse Laravel Laravel Package

Product Decisions This Supports

• New capability scoping: v0.2.8 introduces opt-in "durable partner provisioning" for Laravel, giving product a concrete path to support partner/tenant onboarding (credential issuance and lifecycle) as a roadmap item rather than an ad-hoc integration.
• Build vs. buy: This is the buy/package route for hard provisioning problems — encrypted local intent/result records, afterCommit queue dispatch, a recovery scanner, fenced leases, and idempotent retry semantics. Choosing this package avoids building and maintaining an idempotent provisioning state machine, retry classifier, and stale-worker fencing in-house.
• Feature-flag / staged rollout decision: Provisioning is disabled by default, and installing the release "runs no migration or HTTP request." This supports a decision to ship the integration dormant behind an explicit customer hook, then enable per-customer only after backend and policy readiness.
• Reliability/SLA positioning: Stable key/payload across timeouts and queue failures, plus fenced leases preventing stale-worker overwrites, supports roadmap claims around at-least-once-safe provisioning and crash/retry recovery.
• Security posture decision: Namespace digests, binary original comparison, and primary reads to prevent credential crossover support a security review sign-off on multi-tenant/partner credential isolation.
• Deferral decision: The backend is a separate draft PR, not deployed, and MySQL plus the broader Laravel runtime matrix are not validated. This justifies keeping the item in "pilot/design partner" status rather than committing to a GA date or marketing the feature.
• Dependency decision: Adoption implies taking sabbajohn/pulse-php:^0.1.5; a PM should confirm this constraint against the platform's dependency and upgrade cadence.

When to Consider This Package

• Adopt when:
  • You are on Laravel and need partner/tenant provisioning with durable, retry-safe semantics.
  • You run queue workers and can operate the recovery scanner (afterCommit dispatch assumes functioning queues).
  • You can publish and run the explicit migration tag deliberately, and have DB/storage you can validate (note: MySQL is not validated in this release).
  • The provisioning backend (currently a draft PR) is merged, deployed, and compatible.
  • You have an approved credential-handling policy and an authorized credentials resolver in place.
  • You are comfortable with a safety-by-default, opt-in rollout and can gate the explicit customer hook.
• Look elsewhere / wait when:
  • You are on MySQL or an uncovered Laravel runtime and cannot absorb an unvalidated path.
  • You need a GA/stable integration — the backend is a draft PR and the release is 0.x.
  • You cannot run queue workers plus a recovery scanner (e.g., no durable queue infrastructure).
  • You require synchronous provisioning or cannot tolerate eventual-consistency recovery.
  • You cannot take the sabbajohn/pulse-php:^0.1.5 dependency or are locked to incompatible versions.
  • You have no approved policy/credentials resolver to wire the explicit customer hook.

How to Pitch It (Stakeholders)

To executives: This release adds a durable, encrypted, retry-safe partner provisioning capability for our Laravel apps. It is off by default — installing it triggers no migration and makes no network calls — so the blast radius is near zero until we deliberately enable it per customer. It offloads credential-lifecycle complexity (idempotency, lease fencing, retry classification) to the package instead of custom code. Caveat for planning: the backend is a draft PR that is not deployed, and MySQL/runtime coverage is unvalidated, so treat this as a controlled design-partner pilot, not a GA launch.

To engineering: v0.2.8 requires sabbajohn/pulse-php:^0.1.5 and provides encrypted intent/result persistence, an explicit migration publish tag, afterCommit queue dispatch, and a recovery scanner. It guarantees a stable key/payload across timeouts and queue failures, uses fenced leases to block stale-worker overwrites, and prevents credential crossover via exact namespace digests, binary original comparison, and primary reads. Terminal HTTP errors stop retries even with HTML/malformed bodies; transient errors honor Retry-After. Enablement is a deliberate sequence: configure the explicit customer hook, publish/migrate, wire worker/scanner and the authorized credentials resolver — only after the compatible backend and approved policy are ready. Do not assume MySQL or the extended runtime matrix is validated.