Scenario Core Laravel Package

Technical Evaluation

What we are actually evaluating. stateforge/scenario-core is described only as the "core implementation of scenario framework." It ships under BSD-3-Clause, has 2 stars, 0 dependents, and a single release dated 2026-04-19. There is no evidence of production usage anywhere in the ecosystem. The "score" of 9.43 should not be read as a proxy for maturity — with two stars and zero dependents, it is a signal with almost no statistical weight. The package is, for planning purposes, an unproven, pre-adoption component.

Architecture fit.

• If this is a test/scenario harness (fixtures, scenario orchestration, state seeding), it fits as a require-dev dependency in the test layer only — the lowest-risk position, easily removed, no production runtime exposure.
• If this is a state-machine or scenario-execution engine, the fit is materially different: it enters the domain layer, and any API churn becomes a refactor of business logic. The name "core implementation" suggests the package is a foundation others are meant to build on, which is the more dangerous of the two placements.
• The package's Composer namespace (stateforge/…) does not match the repository owner (laloona/…). That is not disqualifying, but it is an unresolved trust question I would want answered before composer require.

Integration feasibility.

• Composer installation is mechanically trivial; the real question is constraint compatibility (PHP version range, Laravel/Symfony versions, PSR-4 autoloading, whether it registers a service provider or publishes config).
• BSD-3-Clause is permissive and business-friendly: we can fork, vendor, and modify without copyleft exposure. That is the package's strongest attribute and materially reduces the long-term risk of adoption.
• With zero dependents there is no community-tested upgrade path, no known-good matrix of framework versions, and no third-party bug reports to learn from. Every integration issue will be ours to discover and fix.

Technical risk.

• Bus factor of one. Single maintainer, single repository, no visible governance.
• Abandonment risk is high. A 2026-04-19 release with no dependents six-plus months of observable history suggests either a very new project or a dormant one; both imply we may become the de facto maintainer.
• API instability. Early-stage packages typically sit at 0.x, where minor bumps may break. Without a published deprecation policy, upgrades are unquantified work.
• Supply-chain exposure. Low-adoption packages are prime typosquat targets; the vendor/repo name mismatch raises the bar for verification (signed tags, reproducible builds, commit provenance) before it enters our build.
• Documentation risk. No evidence of docs, examples, or a changelog; the source is the specification until proven otherwise.

Key questions to answer before any code is written.

1. What problem does "scenario" solve here — test fixtures, behavioural flows, or runtime state orchestration? Is it dev-only or production-path?
2. What are the declared PHP and Laravel version constraints, and is there a CI matrix proving them?
3. Is there test coverage for the package itself, and what is the ratio of tests to implementation?
4. Who is laloona relative to stateforge, and is the release artefact signed/tagged from the published repository?
5. Is there a documented public API with a stability commitment, or is it source-only?
6. What is the maintainer's stated intent — a library for others, or an extraction from a private project?

Integration Approach

Stack fit. The package is Composer-native and framework-agnostic in appearance, so it will install into a Laravel codebase without ceremony. Fitting it architecturally is the work: it must sit behind an internal interface we own (a thin adapter or repository-style wrapper) so that the concrete library can be swapped or forked without touching call sites. This is non-negotiable given the adoption profile.

Migration path.

• Do not retrofit existing tests or domain code onto this package. Greenfield scope only.
• Pilot in a single bounded context, ideally a low-traffic internal service or a single test suite, so the blast radius is a revert of one composer.json line.
• Vendor the dependency (Composer vendor/ committed or a private mirror) for any deployment that depends on it, so an upstream deletion or force-push cannot break our build.
• If the pilot succeeds and the API stabilises under our usage, treat a hard fork under our namespace as the default end state, not the fallback. BSD-3-Clause makes this clean; the fork also becomes our insurance against abandonment.

Compatibility posture.

• Pin an exact version ("stateforge/scenario-core": "0.x.y") — no caret ranges on a pre-1.0 package with no dependents.
• Record the PHP/Laravel versions validated in the pilot and treat any framework upgrade as a re-validation event.
• Confirm license attribution requirements are satisfied in our distribution (BSD-3-Clause requires retaining copyright notice and disclaimer).

Sequencing.

1. Source review (1–2 days): read the entire codebase — it is small enough to read in full — and answer the key questions above. This is cheaper than any spike and often ends the evaluation.
2. Sandbox spike (2–3 days): install in a throwaway Laravel app, exercise the API, measure how much boilerplate it removes versus what we would write ourselves.
3. Adapter layer (1–2 days): define our internal interface and implement it over the package.
4. Pilot (1 sprint): one test suite or one internal service, non-production-path only.
5. Decision gate: adopt, fork, or replace with ~100 lines of in-house code. Explicitly compare against the build-it-ourselves cost — for a small scenario helper, internal code is frequently the cheaper and safer answer.
6. Production exposure: only after the fork/adapter decision, and only with vendoring in place.

Operational Impact

Maintenance. Assume we own this package from day one. Realistic annual cost: a few days per year of dependency hygiene in the best case, and a multi-day unplanned refactor in the worst case if the maintainer makes a breaking change or disappears mid-upgrade. Budget for a named internal owner — an unowned third-party dependency is how technical debt accumulates silently.

Support. There is no community: no Stack Overflow corpus, no issue-tracker history with useful signal, no third-party tutorials, no consultants. Internal support means reading the source. Issue response time from the maintainer is unknown and should be assumed slow until demonstrated otherwise.

Scaling. Two distinct concerns:

• Scenario definition scaling — scenario/state definitions tend to accrete into a shared, high-coupling configuration surface. Plan for ownership boundaries per domain from the start, or the framework becomes a coordination bottleneck across teams.
• Runtime scaling — if this executes in a request path (rather than tests), profile it before committing. Unproven libraries frequently lack caching, lazy resolution, or batching.

Failure modes to design against.

• Abandonment → mitigated by fork + vendoring.
• Breaking change on a minor bump → mitigated by exact pinning and an adapter boundary.
• Framework upgrade blockage (package not compatible with the next Laravel/PHP LTS) → mitigated by the fork option; track the upstream's constraint file as an early-warning indicator.
• Silent behavioural change in scenario resolution → mitigated by characterisation tests written against our expected outcomes, not the library's own test suite.
• Supply-chain tampering / typosquat → mitigated by verifying repository provenance and vendor/repo ownership before first install.

Ramp-up. The API surface is likely small enough that an experienced Laravel engineer is productive in under a day — if documentation exists, which is unconfirmed. Realistically, budget one to two days for the first engineer to read the source and write internal usage notes, and treat those notes as the onboarding artefact for everyone after them. Without them, each new engineer re-derives the same knowledge.

TPM verdict. The license and installability are fine; the adoption signal is effectively zero and the ownership risk is concentrated in one person. This is a low-cost-to-try, moderate-cost-to-own dependency. Approve only as a time-boxed spike behind an adapter, with a fork-or-replace exit criterion and an explicit comparison against building the equivalent in-house. Do not let it reach a production path without a named owner and vendored source.