Core Laravel Package

Technical Evaluation

Architecture fit. streams/core is not a utility package — it is the engine layer of an opinionated application platform, sitting on top of Eloquent and introducing a parallel data-modeling vocabulary (streams, assignments, field types, repositories, criteria). It fits one profile well: a Laravel application whose core product requirement is configurable, rapidly-evolving data structures — CMS-style content types, admin/back-office tooling, internal data-management apps. It fits poorly everywhere else, because it competes with rather than complements conventional app/Models persistence. Core is also deliberately incomplete: the user-facing value (control panel, UI, addons) lives in sibling repos (streams/platform, streams/ui), so "install core" is not a shippable story on its own.

Integration feasibility. Installation is mechanically simple (Composer, publish config/migrations, register provider, define streams, read/write via repositories). The real feasibility constraint is the multi-repo dependency graph: a working implementation pulls several pinned sibling packages, each with its own Laravel/PHP constraints. Expect to conform your runtime to the package, not the reverse. This is verifiable in days, not weeks, and should be verified before any roadmap commitment.

Technical risk — high, and mostly non-technical in nature.

• License (NOASSERTION) is a hard legal gate, not a checklist item; usability is undetermined until resolved.
• Adoption signal is thin. 170 stars and 0 dependents means no downstream ecosystem to absorb breaking changes and no evidence of sustainable maintainer bandwidth. Default assumption should be "effectively unmaintained."
• Framework drift is near-certain; the supported Laravel/PHP window likely trails current LTS, forcing either an unsupported matrix or an internally owned fork.
• Exit cost is asymmetric. Stream schemas are derived, not authored in migrations, so backing out requires reverse-engineering generated tables into conventional migrations. Budget this up front.

Key questions for the TPM to force closures on.

1. What is the actual license, and has legal accepted it?
2. Which Laravel/PHP versions are supported, and does adopting this force us off our standard runtime?
3. Is core usable without streams/ui, or does any real feature pull in the whole family?
4. What is the last release/commit date, and is there a named, responsive maintainer?
5. What is the net saving versus Filament, Nova, or hand-rolled CRUD over Eloquent — after learning curve and fork ownership?
6. If the project dies in 18 months, what is our remediation cost and timeline?

Integration Approach

Stack fit. Adopt as an isolated subsystem, not a platform bet. Target one bounded domain with a clean seam (repository interfaces at the boundary), keep the rest of the application on standard Eloquent, and preserve the ability to swap implementations without touching callers. Stream definitions must not become the schema of record for core business entities.

Migration path. Greenfield module only. Retrofitting existing tables into streams — rewriting migrations, models, and queries into an unsupported paradigm — is high-cost and low-reversibility. If the bounded module succeeds and the dependency proves healthy, expand scope deliberately; if it fails, you delete one namespace.

Compatibility. Plan for a fork as the baseline operating model, not a contingency. Stand up an internal fork pinned to a known commit, sourced via a Composer VCS/path repository, with Laravel constraints widened as needed. Confirm all sibling package versions resolve together on your target Laravel before feature work begins.

Sequencing.

1. Gate 0 — License + maintenance review. Legal sign-off and a maintainer-activity read. Stop if either fails.
2. Gate 1 — Two-day spike. Fresh Laravel app, one stream with two field types, one criteria-based query, one write path. Proves the package boots on a defensible Laravel version.
3. Gate 2 — Fork, pin, CI. Establish the internal fork and a documented upgrade policy.
4. Build the bounded module behind interfaces, with contract tests identical to those you'd use for an Eloquent implementation.
5. Decide on UI separately. Evaluate streams/ui under the same gates or build a thin admin surface yourself — the latter is usually cheaper than inheriting a second stale dependency.
6. Write the exit note (how to revert the module to plain Eloquent) while context is fresh.

Operational Impact

Maintenance. This becomes an owned dependency on day one. Expect to carry the fork, patch Laravel compatibility, and triage security advisories internally. Allocate recurring engineering capacity — realistically a fraction of an FTE — and treat "no maintainer response in 30 days" as the default assumption rather than a failure mode.

Support. No vendor, no SLA, no community of scale. The only support surface is internal documentation and a named code owner. Onboarding material must be written, not linked.

Scaling. The engine resolves stream/assignment metadata at runtime to build queries; without an aggressive cache layer expect additional round trips per request versus hand-written models. This is manageable but must be measured under realistic load during the spike, not assumed. The harder scaling constraint is organizational: the pool of engineers who know this paradigm is effectively zero, so capacity does not scale by hiring.

Failure modes to monitor.

• Schema drift between stream definition files and the live database — derived schema with no conventional migration history is hard to audit and harder to roll back.
• Cache invalidation on stream/assignment changes — stale metadata produces wrong columns, not clean errors.
• Override leakage into non-stream Eloquent models via global customization, causing confusing behavior in unrelated code.
• Field-type registry collisions when extending custom types across split packages.
• Silent framework incompatibility on Laravel upgrades — loose constraints will not fail loudly at install.

Ramp-up. Budget two to four weeks before a competent Laravel developer is productive. The cost is unlearning conventions: streams vs. migrations, assignments vs. columns, criteria vs. query scopes, repositories vs. models. With no tutorials or Stack Overflow coverage, every non-obvious question is answered by reading source. This learning tax plus fork ownership must be in the business case — on pure cost math the package rarely beats Filament or hand-rolled CRUD. It wins only if config-driven modeling is itself the product requirement.

Recommendation. Do not adopt as a platform foundation. Consider only as a bounded, forked, internally owned component for a configurable-data use case, and only after license and maintenance gates clear within a single sprint. If those gates cannot clear, build the same repository/criteria abstraction in-house over standard Eloquent — keep the good idea, discard the dependency risk.