Core Laravel Package

Technical Evaluation

What the evidence base actually supports. kreta/core presents as the foundational package of the Kreta ecosystem: service-provider integration and auto-discovery, shared contracts and base abstractions, publishable configuration, and extension points for downstream modules. That is a coherent and conventional shape for a Laravel modular platform. What we cannot verify from the registry alone is equally material — zero stars, a composite score of 0, zero dependents, no surfaced version history, license, maintainer activity, or Laravel/PHP constraint set. For a TPM the asymmetry matters: the description tells us what the package intends to be, while the metadata tells us nobody has yet validated that it is that thing.

Architecture fit — this is a platform decision, not a library decision. A "core" package is a trunk: contracts, base classes, and configuration conventions that sibling modules compile against. Adopting it is therefore not the selection of a utility but a commitment to a module architecture and a domain vocabulary (institutions, people/roles, enrollments, academic periods, records). If Kreta is genuinely the target ecosystem, kreta/core is the correct entry point and the roadmap can be sequenced as thin vertical slices over a stable kernel — a genuinely useful planning property for phased, single-institution-then-multi-institution rollouts. If Kreta is not the target ecosystem, the package is inert at best and an architectural anchor dragging us toward a domain model we did not choose at worst. The fit question must be answered at program level, not delegated to a sprint-level engineering ticket.

Integration feasibility — mechanically trivial, evidentially unproven. Composer will resolve the package; installation is not the risk. The risk is that a core package with no downstream consumers has plausibly only ever been exercised by its author, on the author's machine, against the author's Laravel version. There is no visible CI, static analysis, or test evidence to contradict that reading.

Technical risk register.

Key questions, each with a named answerer. These are the gates a TPM should track as explicit decisions rather than letting them dissolve into implementation chatter:

1. Scope — contracts and abstractions only, or concrete implementations (DB, auth, queue, HTTP)? (Engineering lead)
2. Compatibility — explicit illuminate/* constraints, and which Laravel and PHP versions are actually tested in CI? (Engineering lead)
3. Usability — does it stand alone, or hard-require sibling Kreta packages? Does it fail loudly when they are absent? (Engineering lead)
4. Global behavior — does it register middleware, facades, config publishing, or bootstrapping that leaks into unrelated parts of the application? (Engineering lead)
5. License and provenance — what is the license, who maintains Kreta, and what is the commit cadence over the last 12 months? (TPM / legal)
6. Dependency footprint — what does it pull in transitively, and does any of it duplicate or conflict with what we already carry? (Engineering lead)
7. Exit cost — what would it take, in engineer-weeks, to replace or fork the core? (TPM, with engineering input)

Assessment. The package has not cleared the minimum evidence bar for a production dependency. That is a statement about evidence, not about quality — and the distinction should be communicated precisely. Recommend funding a short, timeboxed spike (see below) rather than either adopting or dismissing on the basis of the registry listing.

Integration Approach

Stack fit is conditional. PHP/Laravel matches our stack, but compatibility is not fit. Fit requires that the package's assumptions about application structure and configuration management align with ours. A core package that expects to own the service container or dictate module layout is a poor fit for an application with established architecture — we would be retrofitting the application to the package. The question to settle first is whether Kreta becomes the organizing architecture for a product surface, or merely a borrowed vocabulary.

Migration path: prefer greenfield containment over grafting. There is no incremental migration worth designing before the spike completes, and the honest strategic position is that a "core" package is the worst possible candidate for retrofitting into an existing Laravel application. If Kreta is genuinely a platform bet, the sane entry point is a bounded, self-contained surface — an internal admin tool, a sidecar service, a single-institution pilot — where the platform owns the whole application and our existing code is not asked to coexist with it. This also gives the roadmap a low-cost proof point and a clean abort path.

Compatibility must clear on two independent axes. Framework: the package must declare and test against our current Laravel major; we are not downgrading the platform for an unproven dependency. Runtime: PHP floor must match, since core packages are where version-gated syntax and deprecated constructs accumulate. Both are binary gates, not trade-offs to negotiate.

Sequencing — gated stages with explicit exit criteria. The purpose of this structure is to let us stop cheaply at every step. Steps 1–3 are a bounded spike; step 4 is where real cost begins and requires a sponsor.

Decision checkpoints. Stage-1 completion is a TPM-owned go/no-go on proceeding at all. Stage-3 is the real inflection point: if the API is undocumented and unreadable, stop — the ongoing cost of integration friction will exceed the cost of writing the narrow slice ourselves. Stage 5 must not open without a business sponsor and a stated exit plan, because a core dependency without an exit plan is an unbudgeted liability.

Fallback is the likely correct outcome, and should be stated as a baseline rather than a failure. A service provider, a handful of contracts, and some base classes is typically a few hundred lines of code — fully understood, fully owned, no abandonment risk. The package must justify itself against that baseline. Framing the spike this way is important politically: the deliverable is a decision with evidence, and "build the thin slice in-house" is a legitimate, low-drama result.

Operational Impact

Maintenance is the dominant concern and the primary reason for current caution. A core component is simultaneously the least likely layer to be forked and the most expensive to replace — the worst combination for an unproven dependency. With zero dependents and no visible release cadence, the operating assumption must be that we eventually own the code. The question is therefore not will it be maintained but are we staffed and willing to maintain it. If the answer is no, the decision is already made and the evaluation should be closed rather than prolonged.

Support is effectively absent. Zero dependents means zero community: no Stack Overflow corpus, no third-party write-ups, no downstream bug reports surfacing issues before they reach us. Support cost transfers entirely to internal headcount, and it transfers unevenly — it lands on whichever one or two engineers read the source during the spike, creating a knowledge concentration problem that outlasts the evaluation.

Scaling has two dimensions and both need explicit treatment. Technically: a core package's performance and query patterns are inherited by every module built on it; a naive base abstraction compounds multiplicatively across the product surface, and correcting it means coordinating a change across every dependent module at once. Organizationally: the package's stated purpose — keeping modules consistent, reusable, and maintainable — is a bet that a shared kernel reduces coordination cost as the team and module count grow. That bet only pays if the kernel is stable and documented. An unstable unproven core increases coordination cost, because every module team must independently verify core behavior.

Failure modes to plan against. (a) Silent partial install — the package loads without its sibling modules and fails at a deep, hard-to-diagnose runtime path rather than at boot. (b) Framework upgrade blockade — a pinned illuminate/* constraint prevents a Laravel major upgrade across the whole product, converting one dependency into a program-wide release dependency. (c) Global state leakage — middleware, facades, or config publishing that alters behavior in unrelated application areas, producing defects far from the integrating team. (d) Maintainer disappearance mid-flight — worst case during a customer commitment, when the fork cost lands at the least convenient moment. (e) Domain drift — the package's modeled lifecycles diverge from a real customer's academic-period or enrollment rules, forcing either a fork or an awkward translation layer.

Ramp-up cost is real and should be budgeted in engineer-days, not assumed away. Because documentation is minimal, onboarding is source-reading, not doc-reading: budget roughly 3–5 engineer-days for the spike participants to become productive, and treat that as a one-time cost that must be repeated for any new team member who touches the core. Note also that this cost is sunk twice in the fallback scenario — the evaluation teaches the domain vocabulary, but if we build the slice in-house, the onboarding investment does not transfer cleanly to the replacement.

Operating recommendation. Run the stage 1–3 spike, timeboxed to two to three working days, with a written findings memo as the deliverable and a named engineering owner. Hold stage 4 pending a business sponsor. In parallel, ask engineering to size the in-house thin-slice alternative so the decision is made against a real baseline rather than against zero. Communicate the current position to stakeholders as evaluating a candidate, not adopting a dependency — and be explicit that a negative outcome from the spike is a cheap success, not a setback.