Core Laravel Package

Technical Evaluation

Architecture fit

• runn/core is a framework-agnostic PHP primitives library (the "core" of the broader Runn Me! family), not a Laravel package. It ships no ServiceProvider, no Facade, no config publishing, and no package-discovery metadata.
• That is a fit only if we intend to keep a pure-PHP domain layer isolated from Illuminate\*. If the target code is conventional Laravel (Eloquent models, facades, helper-driven services), the library adds a parallel idiom rather than reinforcing the framework's.
• Net: architecturally clean, strategically orthogonal to the rest of the stack. Value is concentrated in whichever bounded context we deliberately keep framework-free.

Integration feasibility

• Mechanically trivial: composer require runn/core, PSR-4 autoload, no bootstrapping. A spike can be running in under an hour.
• The real cost is the absence of integration surface — no container bindings, no testing helpers, no Laravel-native exceptions or validation bridges. We would write that glue ourselves and own it.

Technical risk

• Adoption signal is weak. 32 stars and 0 dependents means effectively no production reference base; issue triage, security response, and BC discipline are unverified. Score 0.65 against an opportunity score of 3.96 reads as "interesting idea, unproven artifact."
• Bus factor of one. No evidence of a second maintainer, no foundation backing, no commercial sponsor.
• Licensing. LGPL-3.0 is an outlier in the PHP ecosystem (MIT/Apache dominate). In practice LGPL is workable for SaaS and for dynamically-consumed libraries, but "linking" in PHP is legally ambiguous and our counsel will want a review before this ships in anything customer-distributed. Budget a legal cycle, not a coffee break.
• Runtime compatibility. PHP version support and constraint ranges need verification against Laravel 10/11's illuminate/* tree before we promise anything.

Key questions for the maintainer / spike

1. Supported PHP versions and CI matrix — is 8.2/8.3 green?
2. Test coverage and release cadence over the last 12 months?
3. Is runn/core usable standalone, or does it silently require sibling Runn Me! packages?
4. SemVer commitment — are pre-1.0 BC breaks expected?
5. Who else is running this in production, and can we talk to them?
6. Has anyone obtained an LGPL opinion for a PHP/Composer distribution context?

Integration Approach

Stack fit

• Zero coupling to Laravel means zero conflict risk: it will coexist with Eloquent, Octane, and any queue driver without touching the framework's boot path.
• It also means zero leverage — no config/, no artisan generators, no testing traits. We are buying classes, not an integration.

Migration path

• Greenfield only. Restrict to a new bounded context or a strangler-fig module; do not attempt to retrofit existing domain code onto unfamiliar primitives.
• If the API proves valuable but the dependency proves risky, the fallback is straightforward: fork and vendor under our own namespace. The surface is small enough that this is a realistic exit, which materially de-risks the decision.
• No data migration implied — this is a code-level primitive layer, not a persistence or schema concern.

Compatibility

• Verify composer.json constraints resolve cleanly against our locked illuminate/* versions in a throwaway branch before committing.
• Check autoload namespace collisions and confirm no global function/constant side effects.
• Legal gate on LGPL-3.0 must clear before merge, not after.

Sequencing

1. Spike (1–2 days): install, exercise core primitives against one real domain object, publish findings.
2. Legal review (parallel, 1–2 weeks): LGPL-3.0 opinion for our distribution model.
3. Decision gate: adopt as dependency vs. fork-and-vendor vs. borrow the patterns and hand-roll.
4. Pilot: one bounded context, one engineer, timeboxed to a sprint.
5. Measure: lines of glue code written, friction encountered, divergence from team idioms. Re-evaluate at the end of the pilot — not later.

Operational Impact

Maintenance

• Assume we own this code from day one, regardless of what the maintainer does. No SLA, no support contract, no security advisory channel we can rely on.
• Pinning to an exact version and reviewing upstream diff before any bump is the correct default posture.

Support

• Community-only and very small. Internal wiki documentation of why we adopted it is mandatory; the upstream docs (if any) will not survive contact with onboarding.
• Escalation path is "the engineer who did the spike."

Scaling

• Runtime impact is negligible — these are in-process primitives, not infrastructure. No throughput, memory, or cold-start concerns at our volumes.
• The scaling risk is organizational: a primitive used in fifty places has a wide blast radius if a subtle correctness bug surfaces, and we have no upstream to fix it quickly.

Failure modes

• Abandonment: highest-probability failure. Mitigation: fork-and-vendor option pre-scoped, not improvised.
• PHP major bump breakage: library lags a PHP release, blocks our upgrade path. Mitigation: pin, patch locally if needed.
• Licensing drift/compliance gap: discovered late, forces removal under pressure. Mitigation: legal gate before adoption.
• Silent primitive bug: wrong-but-plausible behavior in a value object or collection used everywhere. Mitigation: characterization tests around every primitive we consume.
• Team rejection: unfamiliar idioms cause engineers to route around the library, leaving a half-adopted dependency. Mitigation: hard pilot boundary and explicit go/no-go.

Ramp-up

• Small API surface — a senior engineer is productive in a day. The cost is not learning the API but learning the justification for departing from Laravel conventions in that module; that argument must be written down or it will be re-litigated every quarter.

TPM recommendation: do not adopt as a general dependency. Run the spike and legal review in parallel, pilot in exactly one isolated context, and treat fork-and-vendor as the likely steady state. The opportunity score is interesting; the adoption signal is not yet sufficient to justify a broader commitment.