Wn Octane Plugin Laravel Package

Product Decisions This Supports

• Performance roadmap investment: Whether to put Winter CMS behind Laravel Octane to cut per-request bootstrap cost. This plugin is the enabling glue — if it isn't viable, the Octane line item on the roadmap stalls or becomes an in-house build.
• Build vs. buy: The alternative to adopting this is writing and maintaining your own Winter↔Octane compatibility layer. At this scope the plugin is a thin shim, so buy/adopt is the default; the decision hinges on maintainer risk appetite, not feature surface.
• Adoption gating via POC: Deciding whether to fund a spike (load test + soak test on a staging copy) before committing to Octane in production. The package makes the POC cheap; the risk you're buying down is state leakage in long-running workers, not the plugin itself.
• Release/version hygiene policy: v1.1.1 is a packaging fix, not a feature release — same code as v1.1.0, re-tagged because Packagist recorded 1.1.0 at a pre-#9/#10 commit. This is a concrete argument for lockfile pinning, commit-hash verification, and never trusting a version number alone in dependency reviews.
• Use cases in scope: high-traffic or bootstrap-heavy Winter CMS sites, and teams already standardized on Octane for their Laravel services; out of scope for low-traffic sites where the operational overhead outweighs the gain.

When to Consider This Package

Consider it when:

• You run Winter CMS and have a concrete latency/throughput target that Octane can plausibly hit.
• Your plugin and theme set is stateless-safe, or you're willing to audit and fix the ones that aren't (request-scoped singletons, mutable statics, global helpers).
• You're on a supported PHP version with Octane installed and are comfortable consuming a community-maintained compatibility plugin with a small maintainer surface.
• You can pin and verify: install 1.1.1 or later, not 1.1.0 — Composer-resolved 1.1.0 returns code from before PRs #9 and #10 because Packagist doesn't follow moved tags.

Look elsewhere (or don't adopt) when:

• You're on plain Laravel — Octane needs no CMS plugin; skip this entirely.
• Your CMS instance depends on heavy plugin state, request-global mutation, or non-reset services; Octane will surface those as intermittent bugs regardless of this package.
• You require vendor SLA, security backport guarantees, or a named maintainer commitment — the honest answer here is in-house or a supported commercial path.
• Traffic is modest: added worker-lifecycle and debugging complexity for negligible gain.

How to Pitch It (Stakeholders)

Executives: A low-cost, reversible performance lever for Winter CMS sites, contingent on a short POC. Cost is engineer time plus operational discipline in deployment; benefit is reduced per-request overhead. Risk is not licensing or spend — it's a small-maintainer dependency and a class of subtle state bugs that only appear under long-running workers. Recommend: fund the spike, decide on measured results, keep a rollback path.

Engineering: Treat it as a thin compatibility shim between Winter CMS and Octane, not a framework. Two things matter: (1) pin to 1.1.1+ — 1.1.0 on Packagist resolves to pre-#9/#10 code, a genuine supply-chain trap; verify the installed commit hash against the tag rather than trusting the version string. (2) The real work is auditing for state leakage across requests — reset services, avoid static/global mutation, and soak-test rather than smoke-test. The 1.1.1 release itself carries no new code, so it's a version bump plus a diligence lesson, not a re-review trigger.

Recommendation: Adopt conditionally behind a staging POC; standardize on lockfile pinning with tag-content verification; revisit if maintainer activity lapses or Octane compatibility becomes a supported Winter core concern.